[Bug] muse-spark-1.3-contributor-free: reasoning encrypted_content was not issued to this caller when switching models in same session #48805

Activity

1. github-actions

   assigned

   nexxeln

   on Sep 13, 2026
2. github-actions commented on Sep 13, 2026

   

   github-actionsbot

   on Sep 13, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [BUG] Forking an existing session replays incompatible reasoning.encrypted_content #37444: Same root cause — replaying incompatible reasoning.encrypted_content from a prior session (fork scenario), same encrypted_content caller-binding rejection mechanism
   • provider: stale composite reasoning item id (rs_A:rs_B) replayed after restart → invalid_request_error #48319: Stale composite reasoning item ID replayed after restart causes invalid_request_error on the same opencode provider path — same class of stale/mismatched encrypted reasoning replay
   • Responses multi-turn fails on strict gateways: replayed reasoning items drop provider id (input.N.id: expected a value) #48441: Replayed reasoning items missing provider IDs cause failures on strict gateways — related reasoning history replay class

   If your issue is distinct (specifically the cross-model switch case within the same session for muse-spark on the opencode provider), please note that distinction in a comment so maintainers can track it separately.
3. Joelincn commented on Sep 13, 2026

   

   Joelincn

   on Sep 13, 2026

   Author

   More actions

   Distinct from #37444 / #48319 / #48441 — this is cross-model switch in the SAME session.

   Update with latest verification on opencode 1.18.30:

   • Config applied to try to suppress new blobs (backup kept at opencode.jsonc.bak.20260914010412):

   {
     "$schema": "https://opencode.ai/config.json",
     "provider": { "opencode": { "models": {
       "muse-spark-1.3-contributor-free": { "options": { "include": [] } },
       "muse-spark-1.3": { "options": { "include": [] } },
       "muse-spark-1.2-contributor-free": { "options": { "include": [] } },
       "muse-spark-1.2": { "options": { "include": [] } }
     } } }
   }

   • New session starting directly with muse-spark-1.3-contributor-free works fine, no encrypted_content error (session ses_f643dfaedffesBqtvGAsRpeffn, logs clean after 2026-09-13T17:12Z).
   • Old polluted sessions (ses_f66202cd9ffeCze6vsn4v6gz1U, ses_f6c6b96a9ffePiDYbHphIWblIr) failed symmetrically in BOTH directions (1.2 -> 1.3 and 1.3 -> 1.2), 30+ reasoning encrypted_content was not issued to this caller errors. Polluted session deleted via opencode session delete, DB verified clean (session / message / part count 0).
   • include: [] only prevents requesting NEW encrypted_content, it does NOT strip history. So it cannot fix already-polluted sessions.

   Why not a dup:

   • [BUG] Forking an existing session replays incompatible reasoning.encrypted_content #37444 is fork + same model (rsn_ / smry_ prefix), mine is same session + different model, no fork.
   • provider: stale composite reasoning item id (rs_A:rs_B) replayed after restart → invalid_request_error #48319 is restart + expired composite rs_A:rs_B, mine reproduces without restart.
   • Responses multi-turn fails on strict gateways: replayed reasoning items drop provider id (input.N.id: expected a value) #48441 is missing id on strict gateways, mine has the blob but caller mismatch.

   Suggestion: same tolerance as the Claude fix in v1.18.27 (thinking.blockBinding), but for OpenAI-style reasoning.encrypted_content on the providerID.startsWith("opencode") path — drop encrypted_content and keep only summary when replaying across different models/callers.
4. 1837620622 commented on Sep 14, 2026

   

   1837620622

   on Sep 14, 2026

   More actions

   Also happens without a model switch: idle/resume of a Muse 1.3 session on 1.18.30 bricks the chat with the same Console encrypted_content caller error.

   #48915

   👍React with 👍3Reacted by haz, Ham3dParsa and Esteban
5. 1837620622 commented on Sep 14, 2026

   

   1837620622

   on Sep 14, 2026

   More actions

   Same class of stale encrypted_content replay. Fix: #48918
6. Joelincn commented on Sep 14, 2026

   

   Joelincn

   on Sep 14, 2026

   Author

   More actions

   Confirming a third trigger of the same root cause, no model switch involved:

   • opencode 1.18.30, default config, single session on muse-spark-1.3-contributor-free
   • Egress rotates across 3 Singapore ASNs (load-balanced); every failure is preceded by socket connection was closed unexpectedly, then ~10s later reasoning encrypted_content was not issued to this caller. The "8-10 rounds" pattern matches keep-alive lifetime, not turn count.
   • Once hit, the session is permanently bricked; switching to 1.2 in the same session fails identically (replays 1.3-issued blobs).

   This matches #48915 (thanks for linking). Endorsing its ask here: on this specific 400, drop reasoningEncryptedContent/itemId, persist cleaned parts, and retry once — same class as the Claude stale-thinking recovery in v1.18.27 — instead of blind retry. Plus either sticky routing for Console sessions or a doc note that free models do not tolerate caller/egress rotation. Happy to provide logs.
7. cwkeam commented on Sep 15, 2026

   

   cwkeam

   on Sep 15, 2026

   More actions

   Same root cause as #37444, and I hit it without any model switch: plain restart + resume (opencode --continue) of a long muse-spark-1.3-contributor-free session (Console/Zen path, xhigh) reproduces the identical 400 immediately — the first resumed turn fails and every retry in that session fails. The stored reasoning parts carry caller-bound continuation state minted by the previous opencode process; replayed into a fresh caller connection, the gateway rejects them. That's #48319's restart trigger, same family, just our error message instead of rs_A:rs_B not found.

   DB evidence (stock ~/.local/share/opencode/opencode.db, pre-cleanup snapshot):

   • part.data reasoning rows look like:
     {"type":"reasoning","text":"<summary>","metadata":{"openai":{"itemId":"rs_…","reasoningEncryptedContent":"Q-Pa…"}}}
   • 233 parts across 7 sessions carried those two fields.
   • message.data error rows: APIError · 400 · "reasoning \encrypted_content` was not issued to this caller"from gatewayhttps://opencode.ai/zen/v1/responses`.

   Workaround that works today (no upstream change): delete metadata.openai.itemId and metadata.openai.reasoningEncryptedContent from stored reasoning parts. The visible reasoning summary/text is preserved, and resumed sessions continue cleanly after restart. I made it durable by installing persistent AFTER INSERT/UPDATE triggers on the part table so the fields never get persisted again — re-runnable stdlib script, idempotent, re-run after any opencode upgrade that rebuilds the store.

   On the proper fix: agree with #37444's patch direction — the request-normalization layer should treat itemId/reasoningEncryptedContent as non-durable continuation state: replay it only for the current in-flight turn (same connection, tool-loop continuation), and keep only the visible summary for historical reasoning when reconstructing input across fork/resume/restart boundaries. The auto-retry fallback in #31236 (on this specific 400, resend once with stale reasoning references dropped) would make all these triggers transparent for every provider.

   One more signal worth triaging separately: #49188 (filed today) reports this now happens in fresh short sessions after 2–3 messages, no resume/compact involved — suggests the Console gateway started enforcing stricter validation/expiry on the replayed encrypted_content. If the normalization fix lands and that repro persists, it points at the gateway side.
8. darman-a11y commented on Oct 7, 2026

   

   darman-a11y

   on Oct 7, 2026

   More actions

   STILL UNSOLVED