fix(llm): handle truncated OpenAI tool arguments

[j34ni]

Issue for this PR

Closes #36766

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

A truncated OpenAI Responses stream can cut a function_call mid-JSON inside its streamed arguments. Previously the parser failed the whole stream at response.output_item.done (and later again at the terminal event), losing the provider's truncated / max_output_tokens diagnosis.

The fix defers the failure decision until the terminal response event, because truncation is only diagnosable there:

• Streamed function_call arguments that fail to parse no longer abort the stream at output_item.done. The call is recorded as an UnparsedTool — only its id, name, and UTF-8 byte count are kept, never the argument contents — and settled when the terminal response event arrives.
• response.completed with truncated: true, or response.incomplete with incomplete_details.reason === "max_output_tokens", classify the tool as truncated and emit a provider-error with classification: "truncated" (new literal added to ProviderFailureClassification).
• A clean terminal event with malformed JSON reports Invalid JSON input for openai-responses tool call <name> instead.
• response.failed, error, and a stream that ends without a terminal event (onHalt) append the pending unparsed-tool diagnostics to the errors they already emit.

An unparsed tool is never dispatched: no tool-call event is emitted for it. The parser never buffers argument contents, so provider-sent data is not leaked into diagnostics.

How did you verify your code works?

• Added a truncated tool arguments test group in packages/llm/test/provider/openai-responses.test.ts covering all five paths: response.completed + truncated, response.incomplete + max_output_tokens, clean completion with malformed JSON, response.failed, and stream end without a terminal event. Tests use deterministic scripted SSE, no live provider.
• bun test test/provider/openai-responses.test.ts passes (5/5 in the new group).
• bun typecheck passes in packages/llm.

Screenshots / recordings

N/A — not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

Related work

Truncated tool arguments are addressed by several open PRs. This PR is the protocol-level detection half of #36766; #37220 covers the recovery half in the core session runner (fail the pending local tool call and ask the model to re-emit, capped at three) and explicitly defers adapter-level detection — the part this PR implements. Because an unparsed tool call emits no tool-call event, a runner-level recovery keyed off the parse failure of a dispatched call does not engage here; instead the classified provider-error surfaces at the terminal response event. #42303 improves the user-facing diagnostic for the same failure in the opencode session layer, and #39473 retries truncated AI SDK streams at the stream level (#37852). The file sets are disjoint, so the four PRs compose without merge conflicts.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Related PRs Found

While not exact duplicates, there are several related PRs addressing truncation and tool argument handling:

1. PR fix(opencode): clarify possible tool argument truncation #42303 - fix(opencode): clarify possible tool argument truncation

   • Related to documenting/handling truncated tool arguments

2. PR fix(core): recover from truncated tool arguments with bounded retries #37220 - fix(core): recover from truncated tool arguments with bounded retries

   • Addresses recovery from truncated tool arguments with retry logic

3. PR fix: retry truncated provider streams #39473 - fix: retry truncated provider streams

   • Focuses on retrying truncated provider streams

These PRs appear to be part of a series of improvements for handling truncation in tool calls and provider streams. PR #42566 (the current PR) seems to take a different approach by making truncation diagnosable via UnparsedTool records rather than just retrying.

You may want to verify that these efforts are coordinated and don't conflict with each other's implementations.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Scope: OpenAI Responses protocol no longer fails the whole stream when a function-call item's streamed JSON arguments are malformed/truncated: the call is parked (id, name, UTF-8 byte count only), lifecycle gets its toolInputEnd, and the terminal response event classifies it as provider truncation vs malformed-JSON-for-finished-call.

• Good design: truncation is only knowable at the terminal event (truncated, response.incomplete, max_output_tokens), so deferring the failure there is correct sequencing, and keeping only metadata (never argument contents) in UnparsedTool is a thoughtful privacy/memory choice — documented in the interface comment too.
• Emitting toolInputEnd and dropping the accumulator keeps downstream lifecycle coherent without ever dispatching the broken tool — right call.
• Classification nit: isTruncatedResponse returns true for any response.incomplete, regardless of incomplete_details.reason. An incomplete caused by content_filter with coincidentally-malformed args would be reported as token truncation. Consider matching on reason === "max_output_tokens" for the incomplete case specifically.
• Edge worth confirming: if the stream dies before any terminal response event, parked tools are never flushed — the turn still fails via the transport error, so nothing is silently swallowed end-to-end, but the specific "arguments were truncated" diagnostic is lost in that path. Acceptable trade-off, maybe worth a comment.
• Schema addition (truncated) is optional/additive; tests cover both truncation and malformed-finalized cases per the description.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.