René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Support SSA in InformerEventSource, listen to specific status updates","articleBody":"**Is your feature request related to a problem? Please describe.**\nI am working on a multi-reconciler setup (Main and Secondary) managing the same Custom Resource. The Secondary reconciler updates a specific field within the resource's .status using Server-Side Apply (SSA). The Main reconciler needs to be notified and triggered only when the resource's generation changes OR when this specific status field is updated by the Secondary reconciler.\n\nCurrently, achieving this cleanly is not possible:\n\n- If `generationAwareEventProcessing` is set to `true`, the Main reconciler completely misses the status updates.\n- If `generationAwareEventProcessing` is set to `false`, the Main reconciler is triggered far too often by unrelated status updates.\n- Attempting to pass a custom `OnUpdateFilter` via the `ControllerConfiguration` fails because custom filters are combined with JOSDK's internal filters using a strict AND operation. This prevents implementing a logical OR condition (e.g., `DefaultFiltering OR SpecificStatusFieldChanged`).\n\n**Describe the solution you'd like**\nI would like a way to configure the controller's event filtering behavior to allow logical OR operations between the internal filters (like generation-aware filtering) and user-defined custom filters.\n\nAlternatively, a feature allowing developers to keep `generationAwareEventProcessing = true` but explicitly define a list of observed status paths (e.g., `status.mySpecificField`) that should bypass the generation-aware restriction and still trigger an event would elegantly solve this use case. Or another way to achieve this.\n\n**Describe alternatives you've considered**\n\n1. Setting `generationAwareEventProcessing` to `false`: This causes performance degradation due to a flood of redundant reconciliation loops from other status updates.\n2. Creating a separate `EventSource` on our own resource with an `OnUpdateFilter`: While this successfully isolates the specific status change, it introduces two major downsides:\n- It forces the creation and maintenance of an unnecessary secondary cache.\n- In JOSDK `v5.2.0`, it introduces read-after-write inconsistencies where the resource instance passed to the Main reconciler is outdated at the moment the event source triggers it.\n\n**Additional context**\n- Environment: Java, Micronaut, JOSDK `v5.2.0`.\n- This issue is particularly relevant in advanced operator patterns where responsibilities are split across a Main and a Secondary controller for the same CRD, relying on status fields to pass state back to the primary loop.\n","author":{"url":"https://github.com/bertdw-1985","@type":"Person","name":"bertdw-1985"},"datePublished":"2026-06-11T08:11:11.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/3413/java-operator-sdk/issues/3413"}