allthingssecurity opened a new pull request, #28317:
URL: https://github.com/apache/camel/pull/28317

   # Description
   
   [CAMEL-25844](https://issues.apache.org/jira/browse/CAMEL-25844)
   
   `DaprConfigurationConsumer` subscribed once to the `Flux` of 
`DaprClient.subscribeConfiguration`, without an error or completion handler. 
That `Flux` is one streaming gRPC call to the sidecar: it fails when the 
sidecar restarts or the connection drops, or completes when the sidecar ends 
the call, and the Dapr client does not open it again (`dapr.api.maxRetries` is 
0 by default). Reactor logged the error once as dropped, and the consumer 
stayed started without receiving any further configuration change until the 
route was restarted.
   
   Changes:
   - `DaprConfigurationConsumer.doStart`: subscribe again when the stream fails 
or completes, after one second and then with a growing delay of up to 30 
seconds while the sidecar cannot be reached, for as long as the consumer runs, 
with a WARN each time (the stack trace of a failure only at DEBUG). Stopping 
still disposes the subscription and unsubscribes the current subscription id.
   - Component page (and its catalog copy): one paragraph on the new behaviour, 
and that a change made while the consumer is not subscribed is not delivered.
   
   No option changed, so no upgrade guide entry.
   
   Tests:
   - Two new tests in `DaprConfigurationConsumerTest` (mocked `DaprClient`, as 
the existing test): a stream that fails after its subscription response, and a 
stream that completes. Without the change both fail (`subscribeConfiguration` 
is called once only, no update is routed); with the change both pass.
   - camel-dapr unit tests with the change: 66 run, 0 failures.
   
   How it was found: variant analysis of CAMEL-25843 (a library subscription 
that ends on a recoverable condition while the consumer stays started), then 
the JUnit tests.
   
   What was not run: a real Dapr sidecar; 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-25844](https://issues.apache.org/jira/browse/CAMEL-25844).
   
   # 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-dapr. 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]

Reply via email to