[
https://issues.apache.org/jira/browse/CAMEL-26824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-26824.
---------------------------------
Resolution: Fixed
Fixed by https://github.com/apache/camel/pull/29665 (merged to main for 4.24.0).
> 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
> Priority: Minor
> Fix For: 4.24.0
>
>
> 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)
