[
https://issues.apache.org/jira/browse/CAMEL-23944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Federico Mariani updated CAMEL-23944:
-------------------------------------
Description:
CAMEL-23928 added {{toolExecutionErrorHandler}}, {{toolArgumentsErrorHandler}}
and {{compensateOnToolErrors}} to {{AgentConfiguration}}, correctly wired into
the {{AiServices}} builder. However these handlers can *never fire for Camel
route tools*:
The {{ToolExecutor}} created in
{{LangChain4jAgentProducer.createCamelToolProvider}} executes the tool route on
the *shared live exchange*
({{camelToolSpec.getConsumer().getProcessor().process(exchange)}}, line 302).
When the tool route throws:
* the route pipeline stores the exception on the exchange instead of throwing,
so the executor's catch block (lines 309-312, which would at least return an
"Error executing tool ..." string) never even engages;
* LangChain4j never sees a failure, so the configured
{{ToolExecutionErrorHandler}} is never invoked and {{compensateOnToolErrors}}
is unreachable;
* the raw tool exception fails the whole exchange.
Attached reproducer {{LangChain4jAgentToolExecutionErrorHandlerTest}}
configures a handler via
{{AgentConfiguration.withToolExecutionErrorHandler(...)}} and a tool route that
throws {{IllegalStateException}}: the handler is never invoked and the exchange
fails with the raw exception.
*Suggested fix*: execute Camel route tools on a copy of the exchange (as
camel-langchain4j-tools does via {{ExchangeHelper.createCopy}}), and rethrow
tool failures so LangChain4j's error-handling machinery
({{toolExecutionErrorHandler}} / {{compensateOnToolErrors}}) engages. Keep the
current stringify behavior as the default handler for backward compatibility.
Note: making the tool executor exchange-safe here is also the prerequisite for
exposing {{executeToolsConcurrently}} (tracked in CAMEL-23952).
Related: CAMEL-23928.
_This issue was drafted by Claude Code on behalf of Federico Mariani._
was:
CAMEL-23928 added {{toolExecutionErrorHandler}}, {{toolArgumentsErrorHandler}}
and {{compensateOnToolErrors}} to {{AgentConfiguration}}, correctly wired into
the {{AiServices}} builder. However these handlers can *never fire for Camel
route tools*:
The {{ToolExecutor}} created in
{{LangChain4jAgentProducer.createCamelToolProvider}} executes the tool route on
the *shared live exchange*
({{camelToolSpec.getConsumer().getProcessor().process(exchange)}}, line 302).
When the tool route throws:
* the route pipeline stores the exception on the exchange instead of throwing,
so the executor's catch block (lines 309-312, which would at least return an
"Error executing tool ..." string) never even engages;
* LangChain4j never sees a failure, so the configured
{{ToolExecutionErrorHandler}} is never invoked and {{compensateOnToolErrors}}
is unreachable;
* the raw tool exception fails the whole exchange.
Attached reproducer {{LangChain4jAgentToolExecutionErrorHandlerTest}}
configures a handler via
{{AgentConfiguration.withToolExecutionErrorHandler(...)}} and a tool route that
throws {{IllegalStateException}}: the handler is never invoked and the exchange
fails with the raw exception.
*Suggested fix*: execute Camel route tools on a copy of the exchange (as
camel-langchain4j-tools does via {{ExchangeHelper.createCopy}}), and rethrow
tool failures so LangChain4j's error-handling machinery
({{toolExecutionErrorHandler}} / {{compensateOnToolErrors}}) engages. Keep the
current stringify behavior as the default handler for backward compatibility.
Note: making the tool executor exchange-safe here is also the prerequisite for
exposing {{executeToolsConcurrently}} (tracked in a separate improvement,
"support executeToolsConcurrently").
Related: CAMEL-23928.
_This issue was drafted by Claude Code on behalf of Federico Mariani._
> camel-langchain4j-agent: ToolExecutionErrorHandler and compensateOnToolErrors
> never invoked for Camel route tools
> -----------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-23944
> URL: https://issues.apache.org/jira/browse/CAMEL-23944
> Project: Camel
> Issue Type: Bug
> Components: camel-langchain4j-agent
> Affects Versions: 4.21.0
> Reporter: Federico Mariani
> Priority: Major
> Attachments: LangChain4jAgentToolExecutionErrorHandlerTest.java
>
>
> CAMEL-23928 added {{toolExecutionErrorHandler}},
> {{toolArgumentsErrorHandler}} and {{compensateOnToolErrors}} to
> {{AgentConfiguration}}, correctly wired into the {{AiServices}} builder.
> However these handlers can *never fire for Camel route tools*:
> The {{ToolExecutor}} created in
> {{LangChain4jAgentProducer.createCamelToolProvider}} executes the tool route
> on the *shared live exchange*
> ({{camelToolSpec.getConsumer().getProcessor().process(exchange)}}, line 302).
> When the tool route throws:
> * the route pipeline stores the exception on the exchange instead of
> throwing, so the executor's catch block (lines 309-312, which would at least
> return an "Error executing tool ..." string) never even engages;
> * LangChain4j never sees a failure, so the configured
> {{ToolExecutionErrorHandler}} is never invoked and {{compensateOnToolErrors}}
> is unreachable;
> * the raw tool exception fails the whole exchange.
> Attached reproducer {{LangChain4jAgentToolExecutionErrorHandlerTest}}
> configures a handler via
> {{AgentConfiguration.withToolExecutionErrorHandler(...)}} and a tool route
> that throws {{IllegalStateException}}: the handler is never invoked and the
> exchange fails with the raw exception.
> *Suggested fix*: execute Camel route tools on a copy of the exchange (as
> camel-langchain4j-tools does via {{ExchangeHelper.createCopy}}), and rethrow
> tool failures so LangChain4j's error-handling machinery
> ({{toolExecutionErrorHandler}} / {{compensateOnToolErrors}}) engages. Keep
> the current stringify behavior as the default handler for backward
> compatibility.
> Note: making the tool executor exchange-safe here is also the prerequisite
> for exposing {{executeToolsConcurrently}} (tracked in CAMEL-23952).
> Related: CAMEL-23928.
> _This issue was drafted by Claude Code on behalf of Federico Mariani._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
