[
https://issues.apache.org/jira/browse/CAMEL-25844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-25844:
--------------------------------
Fix Version/s: 4.24.0
> camel-dapr - the configuration consumer never subscribes again after its
> stream to the sidecar ends, and receives no further configuration change
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-25844
> URL: https://issues.apache.org/jira/browse/CAMEL-25844
> Project: Camel
> Issue Type: Bug
> Components: camel-dapr
> Reporter: shashank
> Assignee: shashank
> Priority: Major
> Fix For: 4.24.0
>
>
> {{DaprConfigurationConsumer}} (main 20cdb309f7d0, {{doStart}}) subscribes
> once to the {{Flux}} returned by {{DaprClient.subscribeConfiguration}}:
> {code:java}
> Flux<SubscribeConfigurationResponse> responses =
> client.subscribeConfiguration(configRequest);
> subscription = responses.subscribe((response) -> { ... });
> {code}
> The {{Flux}} is one server-streaming gRPC call to the Dapr sidecar. It ends
> with an error when that call fails (the sidecar restarts, which is routine in
> Kubernetes, or the connection to it drops), or completes when the sidecar
> ends the call. The Dapr Java SDK does not open the call again:
> {{DaprClientImpl.createFlux}} applies the client's {{RetryPolicy}}, and
> {{dapr.api.maxRetries}} is 0 by default (SDK 1.18.1, read with javap). The
> consumer passes no error or completion handler, so Reactor logs the error
> once as dropped ({{onErrorDropped}}), and a completion is not logged at all.
> From then on the consumer stays started, the route reports as started, and no
> further configuration change is delivered until the route is restarted. The
> pub/sub consumer of the same component does not have this problem: the SDK's
> {{Subscription}} opens its stream again after an error.
> *Fix*: the consumer subscribes 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 (Reactor
> {{retryWhen(Retry.backoff(...).transientErrors(true))}} and {{repeatWhen}}
> over a deferred {{subscribeConfiguration}}), for as long as it runs, with a
> WARN each time. Stopping the consumer still disposes the subscription and
> unsubscribes the current subscription id. The component page says that a
> change made while the consumer is not subscribed is not delivered (the first
> response of a new subscription carries no items).
> *Tests*: two new tests in {{DaprConfigurationConsumerTest}} (mocked
> {{DaprClient}}, as the existing test).
> {{testConfigurationConsumerSubscribesAgainWhenTheStreamFails}}: the first
> stream sends its subscription response and then fails, the next one carries
> an update. It fails on main ({{Wanted 2 times ... But was 1 time}}:
> {{subscribeConfiguration}} is never called again) and passes with the fix,
> where the update is routed and the consumer unsubscribes the new subscription
> id when it stops.
> {{testConfigurationConsumerSubscribesAgainWhenTheStreamCompletes}}: the same
> with a stream that completes; fails on main ({{Wanted but not invoked}}: no
> exchange), passes with the fix. camel-dapr unit tests with the fix: 66 run, 0
> failures.
> *How it was found*: variant analysis of CAMEL-25843 (pattern: a library
> subscription that ends on a recoverable condition while Camel never notices,
> so the consumer stays started and receives nothing), then the JUnit tests.
> Not run against a real sidecar.
> *Affected*: main, camel-4.23.x, camel-4.18.x and camel-4.14.x (the same
> single subscribe without error handling; read, not run).
> _Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
