[
https://issues.apache.org/jira/browse/CAMEL-25055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-25055:
--------------------------------
Fix Version/s: 4.23.0
> camel-core - Error registry: fix bugs found in a deep review
> ------------------------------------------------------------
>
> Key: CAMEL-25055
> URL: https://issues.apache.org/jira/browse/CAMEL-25055
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.23.0
>
>
> A deep review of the error registry (DefaultErrorRegistry) found the bugs
> below. Each one was reproduced against 4.23.0-SNAPSHOT and has a test in
> ErrorRegistryEdgeCasesTest that fails without the fix.
> Most of them come from one assumption: an exchange has at most one entry, and
> the first one wins. The registry now only merges two captures of the same
> failure (the same exception, or one that wraps the other), as reported by a
> correlated copy and its original exchange (CAMEL-24863 stays covered).
> # *An error that was not handled is recorded as handled.*
> ExchangeFailureHandledEvent means a failure processor ran, not that the
> exception was handled: onException without handled(true), handled(false) and
> a doCatch that throws again were all recorded as handled.
> # *A second failure of the same exchange is dropped.* After a doCatch (or
> onException continued) recorded a handled error, a later failure that failed
> the exchange was not recorded at all.
> # *The failures of the parts of a split replace each other.* Each part's
> failure removed every entry of the parent exchange, so of two failed parts
> only the last was kept (also for multicast, recipient list and seda).
> # *A failure inside onCompletion hides the failure of the route.* The
> onCompletion copy's failure was recorded first and the route's own failure
> was then skipped.
> # *With noErrorHandler, a failure in a route the exchange was sent to is
> recorded with the route the exchange came from.* The node was from the
> failing route, the route id from the first route. The route id is now taken
> from the message history, as the node is.
> # *ErrorRegistry.forRoute(id).clear() does not reset the repeat counts of the
> route*, as clear() of the registry does.
> # *The JMX browse of the error registry fails when two entries have the same
> exchange id* (KeyAlreadyExistsException), as its table was indexed by
> exchange id. It is now indexed by the uid of the entry (a new uid item). This
> could already happen with a parallel split, and is common now that an
> exchange can have more than one entry.
> *Not changed (for a later look)*
> * The message data of a handled error is captured after the failure processor
> ran (so it shows the error response of onException, not the message that
> failed), and the node of an error caught by a doCatch that throws again is
> the node of the new throw.
> * With an error handler of a route that sent the exchange to another route,
> the failure route id may be overwritten by the sending route
> (captureFailureOrigin).
> _Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
