[
https://issues.apache.org/jira/browse/CAMEL-25055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-25055:
--------------------------------
Description:
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_
was:
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_
> 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
>
> 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)
