Client-tool `output-error` state is lost during native interrupt resolution

TanStack AI version

0.48.0

Framework/Library version

@tanstack/ai-client: 0.26.0 | @tanstack/ai-svelte: 0.18.3

Describe the bug and the steps to reproduce it

Server and client tools share output-available / output-error. A server tool that throws or fails output validation becomes a failed ToolResult with { error: message } and state: 'output-error', and the agent loop continues.

A client tool uses an interrupt only because the server must pause while the browser executes.

Resolving that interrupt means execution finished, not that it succeeded. Native resume should keep the same result state. What happens instead:

• onToolCall catches tool and addToolResultForClientTool() errors as output-error. addToolResultForClientTool() also converts output-schema failures to output-error, then calls resolveClientToolOutput({ error: errorText }).
• That object is treated as a successful output and is unrelated to the tool's declared schema.
• validateInterruptResumeBatch() validates every resolved client-tool payload against the successful output schema and stores only the raw payload in clientToolResults.
• There is no result-state field, so the server cannot reconstruct output-error.
• Canonicalization hits the same path. validateCandidate() applies the Standard Schema; applyValidation() separately converts that value to canonical JSON.
• With synchronous validation, a value can pass the schema and throw during applyValidation(). The outer onToolCall catch converts that serialization failure to output-error and retries resolution with { error }.
• With asynchronous Standard Schema validation, the promise chain catches the same serialization failure as invalid-tool-output; it never becomes a failed ToolResult.

When the success schema rejects { error }, the client blocks the native resume as invalid-tool-output, or durable server validation rejects it when the client has no matching schema.

When the tool has no output schema, or its schema accepts { error }, the resume succeeds but reconstructs the failure as output-available.

Both outcomes lose the original result state instead of continuing the agent loop with a failed tool result.

Expected behavior

Native client-tool resume should carry ClientToolResult state across the browser-server boundary.

The interrupt can stay status: 'resolved' because execution completed. Resume metadata should distinguish:

{ state: "output-available", output: unknown }
{ state: "output-error", errorText: string }

• A known output-error from execution, output validation, or canonicalization should resolve the pause as a failed tool result and skip the successful output schema.
• resolveClientToolOutput() should remain success-only. Before local transcript mutation or resume staging, addToolResultForClientTool() should validate and canonicalize an output-available value; either failure should use the explicit output-error path.
• validateCandidate() should enforce the same success invariant for direct resolutions, report either failure as invalid-tool-output, and return an already-canonical value for applyValidation() to commit.
• The server should validate output-available against the tool schema, validate output-error against a fixed canonical error representation, and reconstruct the same failed ToolResult as server execution ({ error: message }, state: 'output-error').
• The agent loop continues instead of rejecting the resume.

Your Minimal, Reproducible Example - (Sandbox Highly Recommended)

https://stackblitz.com/edit/vitejs-vite-xcs8bcc9?file=src%2Fmain.ts

Do you intend to try to help solve this bug with your own PR?

Yes, I am also opening a PR that solves the problem along side this issue

Terms & Code of Conduct

• I agree to follow this project's Code of Conduct
• I understand that if my bug cannot be reliable reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.