Describe the bug
When the AI Agent node's "Batch Processing" option is enabled with a batch size ≥ 2, and two or more items in the same batch both trigger tool calls in the same round, item B's conversation history gets contaminated with item A's tool-call data (tool name, arguments, and results) from the second round onward. Item A's own history can also end up silently dropped.
Root cause
In executeBatch.ts, when merging multiple batch items that each request tool calls, only the first item's metadata (including its previousRequests) is kept — every other item's is silently discarded. In buildSteps.ts, whatever previousRequests survives that merge gets spliced into every item's rebuilt steps unconditionally, with no per-item filtering.
To reproduce
- Build an Agent node workflow with 2+ input items, each needing a distinct tool call.
- Enable Batch Processing with batch size ≥ 2.
- Run with 2+ tool-calling rounds.
- Inspect item 2's (or later) intermediate steps / conversation — it will contain item 1's tool call data mixed in, or be entirely missing its own.
I have a fix and regression tests ready and will open a PR shortly.
Describe the bug
When the AI Agent node's "Batch Processing" option is enabled with a batch size ≥ 2, and two or more items in the same batch both trigger tool calls in the same round, item B's conversation history gets contaminated with item A's tool-call data (tool name, arguments, and results) from the second round onward. Item A's own history can also end up silently dropped.
Root cause
In
executeBatch.ts, when merging multiple batch items that each request tool calls, only the first item'smetadata(including itspreviousRequests) is kept — every other item's is silently discarded. InbuildSteps.ts, whateverpreviousRequestssurvives that merge gets spliced into every item's rebuilt steps unconditionally, with no per-item filtering.To reproduce
I have a fix and regression tests ready and will open a PR shortly.