shashank created CAMEL-26464:
--------------------------------
Summary: camel-core - an AsyncProcessor that throws in a block
whose steps have no error handler (doTry, onException) hangs the exchange
Key: CAMEL-26464
URL: https://issues.apache.org/jira/browse/CAMEL-26464
Project: Camel
Issue Type: Bug
Components: camel-core
Reporter: shashank
Assignee: shashank
Follow-up of CAMEL-26430, CAMEL-26445 and CAMEL-26446 (an {{AsyncProcessor}}
that throws from {{process(exchange, callback)}} instead of setting the
exception on the exchange), named in the review of CAMEL-26446; the same on
main.
The steps inside a {{doTry}} block, and inside an {{onException}}, have no
error handler. When such a step is an {{AsyncProcessor}} that throws, the
exception goes from {{CamelInternalProcessor}} (through {{StepHelper.process}})
up to the reactive work of {{Pipeline}}, {{DefaultReactiveExecutor}} logs and
drops it ({noformat}Error executing reactive work due to ... This exception is
ignored.{noformat}), and the callback is never called: the exchange hangs (and
in a {{doTry}}, the {{doCatch}} never runs). The same processor setting the
exception on the exchange is caught by the {{doCatch}}; a plain {{Processor}}
that throws is caught too (its converter catches it).
{code:java}
from("direct:start")
.doTry()
.process(asyncProcessorThatThrows)
.doCatch(IllegalStateException.class)
.to("mock:caught")
.end();
from("direct:other")
.onException(IllegalStateException.class).handled(true)
.process(asyncProcessorThatThrows)
.to("mock:handled")
.end()
.throwException(new IllegalStateException("failed"));
{code}
Camel's own processors throw from {{process(exchange, callback)}} only in their
"not started" guards ({{RecipientList}}, {{WireTapProcessor}},
{{ThreadsProcessor}}).
*Proposal*
Catch the exception where the step of the block is called (the processor of the
step in {{CamelInternalProcessor}}, or the task of the {{Pipeline}}), with the
same exactly-once rule as the fixes for the error handlers: before the
callback, fail the exchange with it through the reactive executor after the
work already queued there; after the callback, leave it to the caller as today.
The fix for {{noErrorHandler()}} is in {{NoErrorHandler}} (CAMEL-26461), where
a callback object per step exists already; these layers run every step of every
route with pooled tasks, so the exactly-once flag needs care there. Tests as
for those fixes, with a {{doCatch}} that catches the thrown exception, and in
an {{onException}}.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
