[Inbound email] No failed exchange if error route is configured

[Hooghof]

Describe the bug Use case: Inbound email with wrong credentials Error route is configured

To Reproduce Run use case

Expected behavior Show failed exchange

Flow Instance: development Tenant: Regression Tests Name: InboundEmailFG2476

Version not expected: 8 URL not expected: https://development.dovetail.world/flowdesigner/691b2ee2f15cb400070001e9/8/route

Version expected: 7 URL expected: https://development.dovetail.world/flowdesigner/691b2ee2f15cb400070001e9/7/route

https://dovetailworld.atlassian.net/browse/FG-2476

[Hooghof]

Flow Instance: acceptance Tenant: Regression Tests Name: InboundEmailFG2476 URL: https://acceptance.dovetail.world/flowdesign/691b4e18ba6ff8003f000009

Expected: Failed exchanges and transaction with exchanges in the error route Result: failed exchanges, but no transactions and exchanges in the tracing

[skin27]

By default consumers (inbound) doesn't create a failure message. We may need to have bridgeErrorHandler when that's available.

[brunovg]

Created Camel Jira ticket - https://issues.apache.org/jira/browse/CAMEL-22820

[Hooghof]

In both situations that the error route is configured and not configured, the number of failed exchanges stays 0. The red bullet on failed transactions is not shown in both cases. The red bullets on exchanges are visible.

[brunovg]

When a consumer (e.g., imaps) fails to connect and bridgeErrorHandler=true is used in conjunction with a handled(true) error policy, the ManagedRouteMBean statistics are misleading. The failure is not counted in the ExchangesFailed metric, and the ExchangesCompleted metric increments as if the business logic succeeded.

Created new Apache Camel Jira ticket - https://issues.apache.org/jira/browse/CAMEL-22855

[brunovg]

Additional Note: This behavior is not limited to Consumer/Source failures. When an exception occurs during an action step within the route (e.g., a failing to("http://...")), and that exception is caught by the same handled(true) policy, the statistics exhibit the same pattern: ExchangesCompleted increments, while ExchangesFailed remains 0.

[skin27]

The change in the errorHandler that solved the issue, handled=true, was reverted. It worked in this case (the error is send to the sub route), but then the exchange is not in a failed state anymore, but marked as completed (which is not what we want).

Expected functionality

To illustrate our issue, I created four use cases: Three work as expected, but one does not. Each use case consists of an integration with three routes connected to an error handler configured in a route configuration.

Use case 1: Error during exchange

1. Error happens during the exchange in route 2
2. Error is send to the errorhandler with handled=false
3. Error is send further to a subroute where it's processed.

Working: As expected

Use case 2: Error in consumer (bridgeErrorHandler=false)

1. Error happens in the consumer with bridgeErrorHandler=false
2. Error is not send to the errorhandler

Working: As expected

Use case 3: Error in consumer (bridgeErrorHandler=true / handled=true)

1. Error happens in the consumer with bridgeErrorHandler=true
2. Error is send to the errorhandler with handled=true
3. Error is send further to a subroute where it's processed.

Working: As expected

Use case 4: Error in consumer (bridgeErrorHandler=true / handled=false)

1. Error happens in the consumer with bridgeErrorHandler=true
2. Error is send to the errorhandler with handled=false
3. Error is not send further to a subroute where it's processed.

Working: Not as expected (Expected is that error reaches the subroute just as in use case 1)

Note: that when putting the subroute directly in the errorHandler it works as expected, but for managing and configuring we like to have one or more subroute instead of putting all the logic in the errorHandler.

Expected:

[brunovg]

New jira ticket was created on Apache Camel community - https://issues.apache.org/jira/browse/CAMEL-22907