shashank created CAMEL-26824:
--------------------------------
Summary: camel-core - an Error of a recipientList or synchronous
split expression, a data type transformer or the producer of an API component
lets the route continue as if the step succeeded
Key: CAMEL-26824
URL: https://issues.apache.org/jira/browse/CAMEL-26824
Project: Camel
Issue Type: Bug
Components: camel-core
Reporter: shashank
Assignee: shashank
Follow-up of CAMEL-26741 (apache/camel#29525), as asked in its review.
CAMEL-26741 makes the processor adapters ({{DelegateSyncProcessor}}, the bridge
of {{AsyncProcessorConverterHelper}}, the Processor adapter of the bean
component) fail the exchange with an {{Error}} that is not a
{{VirtualMachineError}}, instead of calling the callback in {{finally}} and
throwing the {{Error}} on. These processors have the same pattern ({{catch
(Exception)}}, {{callback.done(..)}} in {{finally}}):
* {{EvaluateExpressionProcessor}}: the expression of a {{recipientList}};
* the synchronous branch of {{MulticastProcessor.process}}: {{split}},
{{multicast}} and {{recipientList}} with {{synchronous=true}} (an {{Error}} of
the split expression, for example);
* {{DataTypeProcessor}} and {{DelegatingDataTypeProcessor}}: a data type
transformer ({{transform}} to a data type);
* {{AbstractApiProducer}} (camel-support): the invocation runs on a thread of
the component, with {{catch (Exception)}} and {{finally callback.done(false)}}.
An {{Error}} of an API method called by reflection is wrapped by
{{Method.invoke}} and fails the exchange, but an {{Error}} outside that call
(creating the client, a method a producer calls directly, {{interceptResult}})
lets the route continue as a success and is then lost silently in the
{{Future}} of {{submit()}}.
So an {{Error}} of the code they call (an {{AssertionError}}, a
{{LinkageError}} such as {{NoClassDefFoundError}}, a custom {{Error}}) lets the
route continue as if the step had succeeded, or reaches the caller after the
callback.
Also found: {{DelegatingDataTypeProcessor}} calls the callback twice when the
{{CamelDataType}} exchange property is missing (once before {{return}}, once in
{{finally}}).
Expected: as for the adapters after CAMEL-26741, such an {{Error}} fails the
exchange (the error handler handles it), and a {{VirtualMachineError}} is left
as before.
The reactive executor, {{MulticastTask}},
{{CamelInternalProcessor.processTransacted}} and {{ContractAdvice}} have the
same gap; they are left for a separate JIRA, as they need their own tests
(parallel, streaming, transacted).
Found in the review of CAMEL-26741; confirmed with tests on the real classes.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
