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

   # Description
   
   [CAMEL-26857](https://issues.apache.org/jira/browse/CAMEL-26857)
   
   Follow-up of #29584 (CAMEL-26447), which is merged; one commit on top of 
main.
   
   When the `doTry` calls a route (such as with `direct`) whose error handler 
redelivers (`maximumRedeliveries` > 0) and then fails unhandled, the 
`CamelRedeliveryCounter` header of those redeliveries stays on the message when 
the `doCatch` takes over the failure, and it is not marked as over, as 
CAMEL-26734 does for a step that was redelivered and then succeeded. A later 
error handler (a failure after the `doTry`, in a route called from the 
`doCatch` or `doFinally` block, in a calling route when the `doCatch` block 
throws, or in a route called later) counted its redeliveries on from that 
header (`incrementRedeliveryCounter` respects a higher header, for nested error 
handlers), and so redelivered fewer times than configured, or not at all. When 
the `doTry` fails in the route itself, no redelivery runs inside the `doTry`, 
and the later error handler gets all its redeliveries. Since #29584 the later 
error handlers run after such a `doCatch` (before, the exchange stayed failure 
handled)
 , which makes this visible.
   
   Change: the `doCatch` marks that redelivery as over when it takes over the 
failure of a called route (in the block where it clears the handled marks that 
route set, #29584), with the same property CAMEL-26734 uses 
(`CamelErrorHandlerRedeliveryOver`, internal). When the `doTry` fails in the 
route, a redelivery header the exchange brought into it (the live count of an 
outer error handler, such as of a calling route that redelivers its call) is 
left as it was, so that case keeps its outcome exactly. The headers stay on the 
message, so the `doCatch` block can still read how often the called route 
redelivered. The marking moves to a static helper, 
`RedeliveryErrorHandler.markRedeliveryOver(Exchange)` (Javadoc: internal API), 
which the redelivery task and `CatchProcessor` call (the task's private method 
of the same name is gone). The 4.24 upgrade guide section of CAMEL-26734 gets a 
paragraph for this case. Main only: it builds on CAMEL-26734 and #29584, which 
are on main only.
   
   Tests, new `DoCatchRedeliveryOverTest` (camel-core; each case with the 
`doTry` calling the failing route, `viaCallee`, and with the `doTry` failing in 
the route, `inRoute`, as a control with the same expected outcome; the calling 
routes have a dead letter channel with `maximumRedeliveries(3)`, the called 
route redelivers 2 times):
   - `laterFailureInTheCallingRouteGetsItsOwnRedeliveries`: the step after the 
`doTry` fails every time: it is called 4 times (the first call and 3 
redeliveries); the `doCatch` saw the headers of the called route 
(`CamelRedeliveryCounter` 2).
   - `routeCalledFromTheDoCatchGetsItsOwnRedeliveries`: a route called from the 
`doCatch` block fails 3 times and succeeds at its third redelivery.
   - `callingRouteGetsItsOwnRedeliveriesWhenTheDoCatchThrows`: a route with a 
dead letter channel calls the route with the `doTry`, whose `doCatch` throws: 
the calling route redelivers its call 3 times (the `doCatch` runs 4 times).
   
   On main's code the three `viaCallee` cases fail (the later step got 1 
redelivery, the route called from the `doCatch` 1 of its 3, the calling route 1 
of its 3), the `inRoute` controls pass. With the change the camel-core tests 
pass (9187 run, 0 failures, 1 error in `ValidatorExternalResourceTest`, which 
needs the network, 45 skipped), with `DoCatchFailureHandledMarkTest` of #29584 
(15) and `RedeliveryAfterRecoveredStepTest` of CAMEL-26734 (4).
   
   
   # 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-26857](https://issues.apache.org/jira/browse/CAMEL-26857).
   
   # 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 the core modules with the formatter and import-sort plugins and 
ran the camel-core tests. 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