davsclaus opened a new pull request, #29416: URL: https://github.com/apache/camel/pull/29416
Fixes [CAMEL-26734](https://issues.apache.org/jira/browse/CAMEL-26734). When a step was redelivered and then succeeded, a later failure counted its redeliveries on from the `CamelRedeliveryCounter` header that the first step left on the message. The later failure could be in another step of the route, or in a route that gets the exchange (or a seda copy of it) next. With `maximumRedeliveries(2)`, a step after one that needed two redeliveries was not redelivered at all, and went to the dead letter channel at its first failure. This is long-standing: it happens on 4.8.0, 4.23.0 and main. camel-chaos found it while the chaos example was being written (apache/camel-jbang-examples#134). An order whose payment needed two redeliveries was parked by route `shipping` at its first failure. ## Cause `incrementRedeliveryCounter` takes `Math.max(field, header) + 1`. Respecting a higher header value is on purpose: a nested error handler that failed (such as the error handler of a route called from a routing slip) has counted its redeliveries there, and the outer error handler must not redeliver them again (see CAMEL-23469 and the `RoutingSlip*Redeliver*` tests). But the header of a step that recovered is not such a count. That redelivery is over. ## Fix - When a redelivered step succeeds, the error handler marks the redelivery as over. It keeps the header value in an internal exchange property, `CamelErrorHandlerRedeliveryOver`, like the existing `CamelErrorHandlerContinuedException`. A property is copied with the exchange, so the mark also reaches a seda copy. - `incrementRedeliveryCounter` and `decrementRedeliveryCounter` ignore a header whose value is marked as over. The first increment of a new failure removes the mark, so a nested error handler that fails later still accumulates its count as before. - The headers stay on the message after the recovery. Existing tests (`DeadLetterChannelTest`, `RedeliveryProcessorThrowsTest`, `RedeliveryFirstDeliveryProcessorThrowsTest` and others) and users read `CamelRedelivered`/`CamelRedeliveryCounter` in the steps after a recovered one. An earlier try that removed the headers broke those 8 tests, so I dropped it. - The mark is removed together with the headers when a failure is handled or continued. ## Tests `RedeliveryAfterRecoveredStepTest`: - a later step of the same route gets its own redeliveries; - so does a route after a seda hand-off; - the headers stay after a recovery; - a routing slip step is still redelivered only by the outer count after a recovered step, as in `RoutingSlipNestedSlipRedeliveryTest`. The first three failed before the fix. camel-core: the full module run passes (9024 tests, 0 failures). I also ran the YAML reproducer from the JIRA live on the patched jar: step two is redelivered and completes. ## Docs - dead-letter-channel.adoc (and its catalog copy): what the headers mean after a redelivered step succeeded. - Upgrade guide 4.24: such routes can now redeliver more often than before. _Claude Code on behalf of Claus Ibsen_ -- 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]
