-
Notifications
You must be signed in to change notification settings - Fork 236
PerResourcePollingEventSource no longer cancels polling on onResourceDeleted after upgrade to 5.3.2 #3276
Description
Bug Report
What did you do?
We recently upgraded to JOSDK 5.3.2 (along with the Fabric8 client to 7.6.1), and we're seeing a regression where PerResourcePollingEventSource seems to behave differently.
On version 5.2.3, if we called onResourceDeleted, the polling would correctly stop because we no longer want it.
But in the latest version, the polling is not cancelled when we call onResourceDeleted in the update method. It only stops if the resource is physically deleted, which also triggers onResourceDeleted.
Steps to reproduce:
- We have a
PerResourcePollingDependentResource - In
createEventSource, we create a PerResourcePollingEventSource - In the
onResourceUpdatedmethod of the event source, if we detect the CR has a certain label (obsolete), we callonResourceDeleted
What did you expect to see?
Polling stops (this worked perfectly in 5.2.3).
What did you see instead? Under which circumstances?
Polling runs indefinitely.
Environment
Kubernetes cluster type:
operator-framework: 5.3.2
kubernetes-webhooks-framework-core: 3.0.1
kubernetes-client: 7.6.1
k8s-api: 1.35.0
$ Mention java-operator-sdk version from pom.xml file
5.3.2
$ java -version
openjdk version "25.0.2" 2026-01-20
OpenJDK Runtime Environment (build 25.0.2+10-69)
OpenJDK 64-Bit Server VM (build 25.0.2+10-69, mixed mode, sharing)
$ kubectl version
Client Version: v1.32.7
Kustomize Version: v5.5.0
Server Version: v1.33.5+orb1
Possible Solution
We did some digging and compared the source code for PerResourcePollingEventSource between 5.2.3 and 5.3.x. The logic in checkAndRegisterTask and onResourceDeleted actually looks functionally identical. Because the class itself hasn't really changed, we are totally stumped on what's causing this. We aren't sure if it's a change in how JOSDK handles cache updates, a shift in the underlying Fabric8 v7 client, or if we are just missing a new configuration requirement.
Additional context
Did something change in 5.3.x regarding how updates are processed for running polling tasks? What is the recommended way in 5.3.2 to ensure an existing polling task is cancelled when a resource is updated to a state we want to ignore?
Thanks in advance for the help!