sergehuber opened a new pull request, #933: URL: https://github.com/apache/unomi/pull/933
JIRA: https://issues.apache.org/jira/browse/UNOMI-1028 ### Problem Sometimes Unomi starts without some of its built-in condition and action types. In CI this shows up as dozens of `ConditionType not found: nestedCondition` failures that pass on a re-run. `AbstractMultiTypeCachingService.postConstruct` scanned the bundles that were already started, and only after the scan registered its bundle listener. When the `services` Blueprint container waits for `PersistenceService`, `postConstruct` runs on a Blueprint extender thread while the Karaf feature thread keeps starting bundles. A bundle that starts during the scan is missed twice: the scan has already passed it, and the listener isn't registered yet. Its predefined types are never loaded. Evidence from the CI Karaf logs (ES job, run 40358001149): - `DefinitionsService` starts scanning at 07:00:58.490 on `Blueprint Extender: 1`. `plugins-base` starts at 07:00:58.527 on `features-3-thread-1`, during the scan. Only 1 of 33 condition types and 5 of 21 action types get registered. - Two other CI runs dropped the `graphql/cxs-impl` and `lists-extension` types the same way (`cdpSessionEventCondition`, `userListPropertyCondition`, `addToListsAction`, …). Those runs failed less visibly, so the race fires more often than the `nestedCondition` failures alone suggest. ### Fix - Register the bundle listener **before** the scan. A bundle that starts during the scan is then either scanned or notified, never missed. - Keep track of which bundles are already loaded, so a bundle seen by both the scan and the listener loads only once. A bundle is removed from that list when it stops, so a restart reloads it. `postConstruct()` also starts from an empty list, so re-initialising reloads everything as before. All subclasses get the fix (definitions, rules, segments, goals, profiles, scopes, patches, JSON schema, Groovy actions). Load order doesn't matter: each type registers on its own, which the listener path already relied on. ### Tests - `AbstractMultiTypeCachingServiceTest`: - A bundle that is still resolved when the scan reaches it, and starts right after, is loaded. - A bundle seen by both the scan and the listener loads once, and loads again after a stop and start. - Both tests fail on master and pass with the fix. - Unit tests pass for `services-common`, `services` (879), `json-schema/services` and `groovy-actions/services`. - ITs: the race is intermittent, so one green run proves little. In the Karaf log, check that every run registers all 33 condition types (`grep -c "Predefined ConditionType registered"`). 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
