Claus Ibsen created CAMEL-25055:
-----------------------------------
Summary: 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
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.
*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).
* The JMX browse table is indexed by exchange id, which can now have more than
one entry.
_Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
