[
https://issues.apache.org/jira/browse/CAMEL-23704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18089485#comment-18089485
]
Karol Krawczyk commented on CAMEL-23704:
----------------------------------------
Hi [~davsclaus], I'd like to work on this. As I cannot assign issues to myself,
could a committer please assign CAMEL-23704 to me (kkrawczyk) and move it to
*In Progress*?
I've validated the issue and prepared a fix. A note from the investigation: the
existing {{LangChain4jToolMultipleCallsTest}} currently asserts that the second
tool receives the first tool's output as its body — i.e. it codified the very
state-leak this ticket reports (both the loop and the test landed in
{{050af78ca}}). The fix therefore updates that test to assert isolation instead.
Approach: each tool invocation now runs on its own independent copy of the
original incoming exchange (a baseline snapshot reused across iterations),
mirroring the multicast/splitter pattern. After each tool, its outcome is
copied back onto the parent exchange via {{ExchangeHelper.copyResults}}, so the
producer output still carries the (last) tool's result and declared argument
headers — keeping the single-tool behavior intact while removing
body/header/exception leakage between sibling tools.
PR: https://github.com/apache/camel/pull/24062
_Reported by Claude Code on behalf of Karol Krawczyk_
> camel-ai - Use correlated exchange copy for multi-tool invocations in
> langchain4j-tools
> ---------------------------------------------------------------------------------------
>
> Key: CAMEL-23704
> URL: https://issues.apache.org/jira/browse/CAMEL-23704
> Project: Camel
> Issue Type: Improvement
> Components: camel-langchain4j-tools
> Reporter: Claus Ibsen
> Priority: Major
> Labels: help-wanted
>
> Follow-up to CAMEL-21937.
> Currently, the LangChain4jToolsProducer.invokeTools() method reuses the same
> Exchange object across all tool invocations in a single LLM response.
> CAMEL-21937 fixed the most critical issue (ROUTE_STOP flag leaking between
> tools), but the shared exchange still allows:
> * Exchange body from one tool leaking to the next tool
> * Tool parameter headers accumulating across tool invocations
> * Exceptions from one tool affecting subsequent tools
> The proper fix is to create a correlated exchange copy (similar to how
> multicast/splitter work) for each tool invocation. Each tool route would
> execute on its own exchange, and the result would be collected from that
> exchange. This fully isolates tool executions and prevents any state leakage
> between tools.
> This also aligns with how other Camel EIPs handle similar fan-out patterns
> where multiple routes process the same exchange independently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
