[I] bug(runtime): muse-spark-1.2-contributor replies are misjudged as truncated — the opencode gateway closes the stream without a finish_reason [maka]

["uzqw (via GitHub)" <gi...@apache.org>]

uzqw opened a new issue, #3548:
URL: https://github.com/apache/maka/issues/3548

   ## What happened
   
   Using `muse-spark-1.2-contributor` through the opencode.ai (zen/go) connection,
   every completed reply is misjudged as truncated. The gateway closes the SSE
   stream at `[DONE]` without sending a `finish_reason`, so the AI SDK
   synthesizes `other`; `settleModelStepOutcome` then treats any
   `other`/`unknown` finish as a truncated stream and fails the step with
   `provider_unavailable` ("Provider stream ended without finishing (other)") —
   even though the model produced a full answer.
   
   Expected: a stream that reached `[DONE]` with content and no failure is a
   normal stop and the turn completes.
   
   ## How to reproduce
   
   Headless, from source, with a sandboxed config (official line):
   
   ```bash
   sb=$(mktemp -d /tmp/maka-iso-XXXX) && mkdir -p "$sb/config/Maka/workspaces/default" \
   && cp ~/.config/Maka/workspaces/default/{connection-catalog.json,credential-vault.json} "$sb/config/Maka/workspaces/default/" \
   && cd "$sb" && XDG_CONFIG_HOME="$sb/config" node <repo>/packages/cli/dist/cli.js run "Introduce yourself" \
      --connection opencode-go --model muse-spark-1.2-contributor --max-steps 5 --yolo
   ```
   
   Observed: `maka run: Provider stream ended without finishing (other)`.
   
   Gateway-level, independent of Maka:
   
   ```bash
   curl -N https://opencode.ai/zen/go/v1/chat/completions \
     -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
     -d '{"model":"muse-spark-1.2-contributor","stream":true,"messages":[{"role":"user","content":"hi"}]}'
   ```
   
   The stream ends with an empty `choices: []` + usage chunk and never emits a
   `finish_reason`. On the same connection, `minimax-m3` and `glm-5.2` always
   send `finish_reason:"stop"`.
   
   ## Why the defect is model-scoped, not provider-scoped
   
   Swept all 29 models exposed by the opencode-go gateway through headless runs
   on 2026-08-23: `muse-spark-1.2-contributor` is the **only** model whose
   stream ends without a finish_reason. 23 others finish normally and 4 are dead
   upstream. A provider-wide leniency would silently mask real truncation on the
   other 28 models, so the fix must be keyed per model id.
   
   ## Why a manual per-model allowlist is the right shape (and consistent with pi)
   
   The missing finish_reason cannot be inferred from the protocol — it is a
   model-specific gateway defect, so it must be registered explicitly. pi's
   coding agent solves the identical problem the same way: `compat.supportsFinishReason`
   defaults to true and a missing finish_reason throws `Stream ended without
   finish_reason`; leniency is granted only by hand-setting that flag per
   provider/model (`packages/ai/src/api/openai-completions.ts` in pi, with the
   same `toolUse`-if-toolcall-else-`stop` inference this fix uses).
   
   Maka's check is deliberately stricter than pi's:
   
   1. **Model-scoped, not provider-scoped.** pi's compat flag disables the
      finish_reason check for an entire provider; here only the registered model
      id is relaxed and every other model on the gateway keeps the strict check.
   2. **A clean EOF is required.** The lenient mapping only applies when the
      stream actually delivered a finish frame (`sawFinish`), produced no
      failure, and emitted content. A stream that dies mid-answer without a
      finish frame is still reported as truncated — a real truncation is never
      promoted to a normal stop.
   3. **Tool-call steps keep their identity.** A step ending at a tool call maps
      to `tool-calls`, not `stop`, so step-limit accounting in `ai-sdk-backend`
      keeps working.
   4. **Existing strict recovery is untouched.** Output-free truncated streams
      are still retried once, and partial-output truncation is still reported
      rather than turned into an `end_turn` (#2604).
   
   ## Environment
   
   - Maka commit: `f19eede03` (main)
   - OS: Manjaro Linux (x86_64, kernel 7.1.8-1-MANJARO)
   - Surface: CLI (headless `maka run` against Runtime Host)
   - Node.js version: v26.7.0 (from source)
   
   ## Logs, screenshots, or additional context
   
   _Investigated with AI assistance; mechanism verified against the gateway via
   curl, against Maka source at `f19eede03`, and cross-checked against pi's
   openai-completions finish-reason handling._


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org

Re: [I] bug(runtime): OpenCode Go Muse Spark is routed to Chat Completions instead of Responses [maka]

["Astro-Han (via GitHub)" <gi...@apache.org>]

Astro-Han closed issue #3548: bug(runtime): OpenCode Go Muse Spark is routed to Chat Completions instead of Responses
URL: https://github.com/apache/maka/issues/3548


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org