DaanHoogland commented on issue #13898: URL: https://github.com/apache/cloudstack/issues/13898#issuecomment-5314006960
Found a second variant of this same pattern while continuing the ManagementServer wiring-test batch: 5 sites use a **two-step indirection** — `String configKey = ManagementServer.PublishActionEvent.key(); ... _configDao.getValue(configKey);` (or the equivalent for `PublishAlertEvent`/`PublishResourceStateEvent`) — instead of `.value()`. This evades both the original `.value()`-replacement survey (which matched the inline `getValue(X.key())` call shape only) and a plain grep for that shape, since the key string is routed through a local variable first. Sites: - `server/src/main/java/com/cloud/event/ActionEventUtils.java:210-211` (`PublishActionEvent`) - `server/src/main/java/com/cloud/event/AlertGenerator.java:70-71` (`PublishAlertEvent`) - `server/src/main/java/com/cloud/storage/listener/VolumeStateListener.java:99-100` (`PublishResourceStateEvent`) - `server/src/main/java/com/cloud/vm/UserVmStateListener.java:125-126` (`PublishResourceStateEvent`) - `server/src/main/java/com/cloud/storage/listener/SnapshotStateListener.java:83-84` (`PublishResourceStateEvent`) All three keys default to `"true"`, but `ConfigurationDao.getValue()` is a raw DB lookup with no defaulting — so `Boolean.parseBoolean(value)` is `false` whenever no row exists for that key, silently diverging from the registered default (rows are normally seeded at startup from the `ConfigKey` default, so this mostly only bites on edge cases in the seeding path, but it's the same latent-divergence risk as the rest of this issue). All five call sites are static utility/listener classes (not Spring-managed manager impls), which may be why they were structured this way rather than a straightforward oversight — worth checking whether `.value()` is even safe to call from a static context at that point in the lifecycle before converting them. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
