allthingssecurity opened a new pull request, #28380: URL: https://github.com/apache/camel/pull/28380
# Description [CAMEL-25857](https://issues.apache.org/jira/browse/CAMEL-25857) The watch consumers of camel-kubernetes (kubernetes-pods, -services, -deployments, -config-maps, -custom-resources, -events, -hpa, -namespaces, -nodes, -replication-controllers and openshift-deploymentconfigs) submitted their watch task to their executor once, in `doStart`. When the Kubernetes client could not create that first watch (the API server could not be reached, or answered 403 because the RBAC rules of the service account were not applied yet), the exception ended the task inside the `Future` that nobody reads: nothing was logged, the consumer never watched again, and the route stayed started without receiving any event. CAMEL-25273 made the consumers watch again when the client closes a watch with an error, and try again with a backoff when that fails. The first watch did not go through that path. Changes: - New `KubernetesHelper.watch(consumer, executor, task)`: runs the watch task on the executor of the consumer; on failure it logs a WARN and tries again with the backoff of `watchAgain` (1 s, doubling up to 30 s) until the watch is created or the consumer is stopped. - A failed attempt is logged as a WARN line with the exception (its stack trace at DEBUG), followed by the INFO line "Watching again for ... in ... ms" of the next attempt, so two lines per attempt (at most every 30 s while it fails). `watchAgain` logged the stack trace at WARN on every failed attempt; as the attempts now also go on from the start of the route while the API server cannot be reached (every 30 s), it logs the same way. - The 11 consumers call it in `doStart` instead of `executor.submit(task)`. No option changed, so no upgrade guide entry. Tests: - New `KubernetesPodsConsumerFirstWatchFailsTest` (fabric8 mock server, as `KubernetesPodsConsumerWatchClosedTest`): the first watch request gets 403, the second one an `ADDED` pod. Without the change: `mock://result Received message count. Expected: <1> but was: <0>`, and the test log has no line about the 403. With the change the pod is received after the retry, and the 403 is logged as a WARN line (followed by the INFO line of the next attempt). - camel-kubernetes unit tests with the change: 180 run, 0 failures, 6 skipped. How it was found: a review of consumers that run their receive loop or watch on their own thread, looking for an exception that ends it while the route stays started; then the JUnit test. What was not run: a test against a real cluster; the full root build. # Target - [x] I checked that the commit is targeting the correct branch (Camel 4 uses the `main` branch) # Tracking - [x] If this is a large change, bug fix, or code improvement, I checked there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for the change (usually before you start working on it): [CAMEL-25857](https://issues.apache.org/jira/browse/CAMEL-25857). # Apache Camel coding standards and style - [x] I checked that each commit in the pull request has a meaningful subject line and body. - [ ] I have run `mvn clean install -DskipTests` locally from root folder and I have committed all auto-generated changes. (I built and tested camel-kubernetes. No option changed. I did not run the full root build.) # AI-assisted contributions - [x] If this PR includes AI-generated code, commits have proper co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR description identifies the AI tool used. This PR was prepared with Claude Code (Claude Opus 5.5). The commit carries a `Co-Authored-By` trailer. _Claude Code on behalf of allthingssecurity_ 🤖 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]
