allthingssecurity opened a new pull request, #28069: URL: https://github.com/apache/camel/pull/28069
# Description [CAMEL-25742](https://issues.apache.org/jira/browse/CAMEL-25742) `CoAPObserver` (the consumer used with `observe=true`) calls `client.observe(this)` on start and drops the returned `CoapObserveRelation`; it has no `doStop`. So when its route is stopped the server keeps it as an observer and every notification is still handed to the stopped consumer (while the route is stopped it fails with `RouteStoppingException`, logged as a WARN). When the route is started again the new consumer observes a second time, and the stopped consumer routes into the started route again: each notification is then routed twice (and once more after every further stop / start). `onError` also observes again after a stop. Change: - keep the relation returned by `observe`; - `doStop` cancels it with `proactiveCancel()` (Californium cancels the observation in the client at once, so no later notification reaches the consumer, and sends the deregistration to the server), then shuts the client down; - `onError` observes again only while the consumer is running. What users can notice: a stopped observe route no longer receives notifications, and a restarted one receives each notification once. Tests: - New `CoAPObserveRestartTest` (2 tests, Camel CoAP server with an observable resource in the same JVM): stop and start the observer route, change the resource once, and the notification is routed once; and stop the observer route, the resource must have no observer, start it again, one observer. - Without the change both fail: `mock://observed Received message count. Expected: <1> but was: <2>`, and the server still holds the stopped consumer's observation (`ConditionTimeout` at the `observerCount() == 0` wait), 3 of 3 runs each. - With the change the camel-coap tests pass: 78 run, 0 failures, 0 errors, 0 skipped. What is not changed (possible follow-ups): the server side `CoAPConsumer` has no `doStop` either, so a stopped route keeps answering requests until a new consumer takes its path; `CoapClient.shutdown()` does not destroy the client's own `CoapEndpoint` (socket and threads). What was not run: 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-25742](https://issues.apache.org/jira/browse/CAMEL-25742). # 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-coap, including the formatter and import-sort plugins. 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]
