fix: NPE in external resource caching event source when only a generic filter is set - #3518
Merged
csviri merged 2 commits intoAug 3, 2026
Conversation
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
16 tasks
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes a NullPointerException in ExternalResourceCachingEventSource when only a generic filter is configured (no add/delete/update-specific filter), ensuring add/delete/update paths remain null-safe and behave as before when specific filters are present.
Changes:
- Make add/delete/update filter evaluation null-safe by delegating to helper methods that treat missing specific filters as “accept”.
- Add regression tests covering add, delete, and update when only
setGenericFilter(...)is set.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/ExternalResourceCachingEventSource.java | Prevents NPE by making specific filter invocation null-safe in add/delete/update acceptance logic. |
| operator-framework-core/src/test/java/io/javaoperatorsdk/operator/processing/event/source/ExternalResourceCachingEventSourceTest.java | Adds regression coverage for generic-filter-only configurations across add/delete/update branches. |
Comment on lines
+159
to
+166
| var anyAddAccepted = | ||
| addedResources.values().stream() | ||
| .anyMatch(r -> acceptedByGenericFiler(r) && onAddFilter.accept(r)); | ||
| .anyMatch(r -> acceptedByGenericFiler(r) && acceptedByOnAddFilter(r)); |
csviri
marked this pull request as ready for review
August 3, 2026 07:48
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
…c filter is set
`acceptedByFiler` guards each of its three filter branches with
`onXFilter != null || genericFilter != null`, but the branch body
dereferences `onXFilter` unconditionally:
if (onAddFilter != null || genericFilter != null) {
... .anyMatch(r -> acceptedByGenericFiler(r) && onAddFilter.accept(r));
So configuring only a generic filter via `setGenericFilter(...)` throws a
NullPointerException as soon as a resource is added, deleted or updated.
All three branches (add / delete / update) are affected, which means
`PollingEventSource`, `PerResourcePollingEventSource` and
`CachingInboundEventSource` all break when used with a generic filter
only.
The existing `genericFilteringEvents` test missed this because it uses a
filter that returns `false`: `&&` short-circuits before the null
dereference. Only a generic filter that accepts a resource reaches the
NPE.
Each filter check is now null-safe (an absent filter accepts), which
preserves the previous behaviour whenever the specific filter is set.
Adds three regression tests, one per branch; they fail with
NullPointerException without this change.
csviri
force-pushed
the
fix/external-cache-generic-filter-npe
branch
from
August 3, 2026 07:49
efbdee9 to
1a97b9d
Compare
csviri
added a commit
to csviri/java-operator-sdk
that referenced
this pull request
Aug 3, 2026
…c filter is set (operator-framework#3518) `acceptedByFiler` guards each of its three filter branches with `onXFilter != null || genericFilter != null`, but the branch body dereferences `onXFilter` unconditionally: if (onAddFilter != null || genericFilter != null) { ... .anyMatch(r -> acceptedByGenericFiler(r) && onAddFilter.accept(r)); So configuring only a generic filter via `setGenericFilter(...)` throws a NullPointerException as soon as a resource is added, deleted or updated. All three branches (add / delete / update) are affected, which means `PollingEventSource`, `PerResourcePollingEventSource` and `CachingInboundEventSource` all break when used with a generic filter only. The existing `genericFilteringEvents` test missed this because it uses a filter that returns `false`: `&&` short-circuits before the null dereference. Only a generic filter that accepts a resource reaches the NPE. Each filter check is now null-safe (an absent filter accepts), which preserves the previous behaviour whenever the specific filter is set. Adds three regression tests, one per branch; they fail with NullPointerException without this change. Signed-off-by: Attila Mészáros <a_meszaros@apple.com> # Conflicts: # operator-framework-core/src/test/java/io/javaoperatorsdk/operator/processing/event/source/ExternalResourceCachingEventSourceTest.java
csviri
added a commit
to csviri/java-operator-sdk
that referenced
this pull request
Aug 3, 2026
…c filter is set (operator-framework#3518) `acceptedByFiler` guards each of its three filter branches with `onXFilter != null || genericFilter != null`, but the branch body dereferences `onXFilter` unconditionally: if (onAddFilter != null || genericFilter != null) { ... .anyMatch(r -> acceptedByGenericFiler(r) && onAddFilter.accept(r)); So configuring only a generic filter via `setGenericFilter(...)` throws a NullPointerException as soon as a resource is added, deleted or updated. All three branches (add / delete / update) are affected, which means `PollingEventSource`, `PerResourcePollingEventSource` and `CachingInboundEventSource` all break when used with a generic filter only. The existing `genericFilteringEvents` test missed this because it uses a filter that returns `false`: `&&` short-circuits before the null dereference. Only a generic filter that accepts a resource reaches the NPE. Each filter check is now null-safe (an absent filter accepts), which preserves the previous behaviour whenever the specific filter is set. Adds three regression tests, one per branch; they fail with NullPointerException without this change. Signed-off-by: Attila Mészáros <a_meszaros@apple.com> # Conflicts: # operator-framework-core/src/test/java/io/javaoperatorsdk/operator/processing/event/source/ExternalResourceCachingEventSourceTest.java
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
acceptedByFilerguards each of its three filter branches withonXFilter != null || genericFilter != null, but the branch bodydereferences
onXFilterunconditionally:So configuring only a generic filter via
setGenericFilter(...)throws aNullPointerException as soon as a resource is added, deleted or updated.
All three branches (add / delete / update) are affected, which means
PollingEventSource,PerResourcePollingEventSourceandCachingInboundEventSourceall break when used with a generic filteronly.
The existing
genericFilteringEventstest missed this because it uses afilter that returns
false:&&short-circuits before the nulldereference. Only a generic filter that accepts a resource reaches the
NPE.
Each filter check is now null-safe (an absent filter accepts), which
preserves the previous behaviour whenever the specific filter is set.
Adds three regression tests, one per branch; they fail with
NullPointerException without this change.
Part of #3517