gnodet commented on PR #24992: URL: https://github.com/apache/camel/pull/24992#issuecomment-5050902381
_Claude Code on behalf of gnodet_ @oscerd Thank you for the thorough review and the clear breakdown of what survived the CAMEL-23382 migration. All requested changes have been addressed: ### Rebase onto current main ✅ The fix has been re-targeted to `AiToolExecutor` (commits `13446c0` and onward). The producer now discovers tools from `AiToolRegistry` and delegates execution through `AiToolExecutor.execute()`, with exchange isolation applied in the `addToolToResult()` path. ### RuntimeCamelException instead of plain RuntimeException ✅ Changed to `RuntimeCamelException.wrapRuntimeCamelException(error.cause())` — the Camel idiom. This ensures `ToolExecutionErrorHandler.handle(Throwable, ToolErrorContext)` receives the real cause directly without needing to unwrap. ### Exchange isolation test actually tests what it claims ✅ `toolExecutionShouldNotLeakStateIntoCallingExchange` now asserts: - Original headers survive tool execution - Tool argument headers (`input`) do NOT leak into the calling exchange - Tool route side-effect headers (`toolSideEffect`) do NOT leak Added a companion test `failingToolExecutionShouldNotLeakStateIntoCallingExchange` for the failure path, confirming isolation is unconditional. ### Upgrade guide entry ✅ Added a new section "Exchange isolation for Camel route tools" to the 4.22 upgrade guide (commit `fba72d6`) documenting: - Tool headers (arguments, side-effects, `CamelToolName`) no longer leak into the calling exchange - Tool execution errors are rethrown as `RuntimeCamelException` - Migration guidance for code that reads tool-related headers from the calling exchange -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
