Versions
@workflow/ai: 4.1.2ai: 6.0.134
Summary
When an assistant tool call has a malformed input (bad JSON, or a value that fails the tool's inputSchema validation), DurableAgent.streamText throws out of executeTool, which propagates up through streamTextIterator and terminates the stream.
The core ai SDK handles the same failure differently: it converts the parse/validation failure into an invalid: true tool call, emits a tool-input-error UIMessage chunk, keeps the loop alive, and lets the model see the validator message on the next step so it can self-correct.
Expected behavior
Schema-shape failures should be recoverable — fed back to the model on the next step rather than killing the stream. Runtime zod validation throws are the normal feedback channel the model uses to fix an argument, so a single bad arg shouldn't end the turn.
This is also internally inconsistent: if the tool's execute function throws after parsing, the error is already converted to an error-text tool result and flows back to the model. Only the parse/validate path is fatal.
Relevant code
@workflow/ai 4.1.2 — executeTool in packages/ai/src/agent/durable-agent.ts (compiled dist/agent/durable-agent.js): after repairToolCall, the catch (parseError) block does throw parseError.ai 6.0.134 — parseToolCall returns { invalid: true, error, … } and stream-text.ts emits a tool-input-error chunk:
Versions
@workflow/ai: 4.1.2ai: 6.0.134Summary
When an assistant tool call has a malformed input (bad JSON, or a value that fails the tool's
inputSchemavalidation),DurableAgent.streamTextthrows out ofexecuteTool, which propagates up throughstreamTextIteratorand terminates the stream.The core
aiSDK handles the same failure differently: it converts the parse/validation failure into aninvalid: truetool call, emits atool-input-errorUIMessage chunk, keeps the loop alive, and lets the model see the validator message on the next step so it can self-correct.Expected behavior
Schema-shape failures should be recoverable — fed back to the model on the next step rather than killing the stream. Runtime zod validation throws are the normal feedback channel the model uses to fix an argument, so a single bad arg shouldn't end the turn.
This is also internally inconsistent: if the tool's
executefunction throws after parsing, the error is already converted to anerror-texttool result and flows back to the model. Only the parse/validate path is fatal.Relevant code
@workflow/ai4.1.2 —executeToolinpackages/ai/src/agent/durable-agent.ts(compileddist/agent/durable-agent.js): afterrepairToolCall, thecatch (parseError)block doesthrow parseError.ai6.0.134 —parseToolCallreturns{ invalid: true, error, … }andstream-text.tsemits atool-input-errorchunk: