[
https://issues.apache.org/jira/browse/CAMEL-24590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-24590:
--------------------------------
Fix Version/s: (was: 4.18.5)
> ManagedRouteGroupMBean.getFailuresHandled() /
> getLastExchangeFailureHandledTimestamp() return 0/null even though a member
> route recorded a handled failure
> ----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24590
> URL: https://issues.apache.org/jira/browse/CAMEL-24590
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 4.21.0, 4.22.0
> Environment: *Java* 25
> *Apache Camel* 4.21.0 / 4.22.0
> Reporter: Bruno Gonçalves
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 4.22.1, 4.23.0
>
> Attachments: last-exchange-failure-timestamp-reproducer.tar
>
>
> When a route group's failure is thrown and handled via
> {{onException(...).handled(true)}} on the route where the exception
> originates, and the exception handler then forwards the exchange to _other_
> routes in the same group (e.g. via {{{}.to("direct:..."){}}}), the
> originating route's {{ManagedRouteMBean}} correctly records
> {{failuresHandled=1}} and a valid
> {{{}getLastExchangeFailureHandledTimestamp(){}}}. However,
> {{ManagedRouteGroupMBean.getFailuresHandled()}} and
> {{getLastExchangeFailureHandledTimestamp()}} for the same group report {{0}}
> / {{null}} — they do not reflect the originating route's counters at all, and
> do not match a sum, max, or any other consistent aggregation across the
> group's member routes.
> This makes group-level failure-handling stats silently wrong for any route
> group where the exception handler hands the exchange off to sibling routes
> within the same group before it terminates — a common shape for tools that
> model multi-step flows as one Camel route group with a route per step.
>
> *Steps to Reproduce:*
> on attach
>
> *Expected result:*
> {{GROUP failuresHandled}} reflects the {{1}} recorded on route {{trigger}}
> (either by summing across members, consistent with how
> {{ManagedRouteGroupMBean.getExchangesFailed()}} is documented to aggregate
> per the route-group manual page, or at minimum by not silently dropping it).
>
> *Actual result:*
> {code:java}
> GROUP completed=1 failed=0 failuresHandled=0 lastFailureHandledTs=null
> route sb-step1 completed=1 failed=0 failuresHandled=0
> lastFailureHandledTs=null
> route sb-step2 completed=1 failed=0 failuresHandled=0
> lastFailureHandledTs=null
> route test-route-setbody-then-hop completed=1 failed=0 failuresHandled=1
> lastFailureHandledTs=Wed Sep 02 11:55:44 WEST 2026{code}
>
> *Additional notes:*
> * {{getExchangesCompleted()}} at the group level does show {{1}} (matching
> all three routes, each of which independently completed normally), so _some_
> aggregation logic exists at the group level — it's specifically the
> handled-failure counters that are dropped.
> * This was found via {{getLastExchangeFailureHandledTimestamp()}} added
> under CAMEL-23615; worth checking whether the same gap exists for the sibling
> {{getLastExchangeFailureTimestamp()}} (unhandled failures) — untested here
> since this repro uses {{{}.handled(true){}}}.
> * Workaround: consumers can iterate {{context.getRoutesByGroup(groupId)}}
> and read {{ManagedRouteMBean.getFailuresHandled()}} /
> {{getLastExchangeFailureHandledTimestamp()}} directly per route instead of
> relying on the group MBean.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
