Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Structured output: gpt-6-luna (reasoning none) adds text after a valid object — allow recovering it, not failing JSON.parse

クローズ
  • 何か問題がありますか？
#1,485 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
52/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
api, backend-api-design

調査の方向性

Start with adapters/text.js and adapters/responses-text.js, tracing structuredOutputStream and structuredOutput parsing, then read harvestCombinedStructuredOutput in activities/chat/index.js. Compare streaming and non-streaming error paths and the existing schema validation behavior. Done means the selected recovery or raw-error approach works consistently across the named paths without losing valid structured output.

索引モデルが issue の本文から書いたものです。

説明

Versions: @tanstack/ai 0.58.0, @tanstack/ai-openrouter 0.19.17

Model and frequency
  • Model: openai/gpt-6-luna through OpenRouter (@tanstack/ai-openrouter 0.19.17, @tanstack/ai 0.58.0), with outputSchema set (strict json_schema) and reasoning effort "none".
  • Frequency: on a long (~65k-token) system prompt with a four-field schema, about 1–2% of calls stream one complete, schema-valid object and then keep writing. Most often the extra text is a second, near-identical copy of the same object. Sometimes it is stray text, such as *****/ or a sentence like "Need valid JSON…". In our logs the second object repeated the first object's field values in almost every case, so the first object is the model's real answer.
  • Reasoning effort matters: the same model with a little reasoning (effort "minimal") produced 0 such replies over a full run of ~1,400 calls.
  • Not a provider issue: restricting OpenRouter routing to endpoints that support structured outputs (provider.require_parameters) did not change the rate (12 vs 13 on the same 100 cases), so it is not one provider ignoring response_format.
  • Recoverable: extracting the first balanced top-level object recovered every one of these replies in our evals (0 needed a retry).
What happens

We use outputSchema on the OpenRouter adapter with reasoning turned off (effort "none") on a small OpenAI model. About 1–2% of calls stream a reply that holds a complete JSON object that passes the schema, followed by more text. Usually the extra text is a near-copy of the object. Sometimes it is a stray remark. Example (anonymized):

{"query":"t:creature ...","preciseScore":9}

{"query":"t:creature ..."}

Strict JSON.parse rejects the whole reply, so the run fails with code "parse-error". The first object is the model's real answer, and it is lost.

The same thing happens when string values hold regex-like content. They can include backslashes that JSON does not allow (e.g. \{), so parsing fails even when the reply is a single object.

Where this happens:

  • @tanstack/ai-openrouter adapters/text.js: structuredOutputStream builds up the streamed text, calls JSON.parse(accumulatedContent), and on failure yields a RUN_ERROR (code: "parse-error"). The message holds only accumulatedContent.slice(0, 200). The non-streaming structuredOutput path in the same file does the same thing.
  • adapters/responses-text.js does the same, in both the streaming and non-streaming paths.
  • @tanstack/ai activities/chat/index.js: harvestCombinedStructuredOutput also calls JSON.parse strictly and keeps a 200-character preview (code: "structured-output-parse-failed"). The normalize hook runs only after JSON.parse succeeds, so there is no hook that can fix the text before it is parsed.
Why it's hard to work around

The error carries only a 200-character preview, and normalize runs after parsing. To recover, a consumer has to collect the raw text itself from TEXT_MESSAGE_CONTENT chunks in a middleware onChunk, then parse it again inside a catch around chat(). This works: it recovered all 21 of these failures in our eval suite. But it is fragile, depends on the adapter's chunk shape, and has to be duplicated for each adapter path.

Proposal

Any one of these would solve it:

  1. An option on chat() / outputSchema that runs before JSON.parse, such as parseStructuredOutput?: (raw: string) => unknown or repair?: (raw: string) => string.
  2. Built-in lenient extraction: before giving up, take the first balanced top-level object and parse that.
  3. At the very least, attach the full raw text to the error (e.g. error.raw) instead of a 200-character preview, so consumers can recover without capturing chunks.

For reference, our repair is about 30 lines:

  1. Take the first balanced {...}, tracking strings and escapes.
  2. If that still fails to parse, double every backslash that is not followed by a valid JSON escape character.
  3. Validate the result against the schema.

Glad to share the code if it helps.

主要言語
TypeScript
スター
3.1k
フォーク
340
平均マージ
2日 11時間
マージ済み PR（30日）
170

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

TanStack/ai のほかの issue

TanStack/ai の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。