server: drain replay of pending step fails with Mistral 400 ('str object' has no attribute 'items') and retries every ~15s #51452

Activity

1. github-actions

   assigned

   kitlangton

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

   

   github-actionsBot

   on Sep 26, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Web UI session stuck for hours with upstream invalid_request_error: no diagnostics, endless retry, no reliable recovery #45456: long-running sessions fail during drain with upstream 400s, repeated retries, and missing request-body diagnostics.
   • compaction sends mutated thinking block -> permanent 400 retry loop #39291: replayed/mutated thinking state causes provider 400s and a persistent retry loop.
   • [v2] One-shot provider-overflow recovery does not engage when the provider returns an opaque 400 (e.g. bare "invalid request") — session dead-ends with no recovery #46564: an opaque provider 400 leaves a V2 session repeatedly failing in the drain path without recovery.
   • Session permanently frozen: drain() failures are logged but never surfaced to the client (no session.error event) #49740: drain failures are logged but not surfaced to the client, leaving sessions stalled.
3. Phototonic commented on Sep 26, 2026

   

   Phototonic

   on Sep 26, 2026

   Author

   More actions

   Checked all four candidates — confirming the relationship of each rather than plain duplicate status:

   Same root-cause family as #39291 / #45456 (replayed reasoning/thinking state rejected by the provider on request rebuild), but this report differs on three axes:

   1. Trigger: SessionRunner.drain resuming a pending step after a service restart — not compaction (compaction sends mutated thinking block -> permanent 400 retry loop #39291) and not a generic long-running-overflow case (Web UI session stuck for hours with upstream invalid_request_error: no diagnostics, endless retry, no reliable recovery #45456).
   2. Provider stack: native Mistral integration (@opencode/ai/providers/mistral, zai-glm-5-3) with a Python-side backend error — 'str object' has no attribute 'items', i.e. a string arriving where a dict/object is expected — rather than Anthropic's byte-identical-thinking rejection or a bare invalid_request_error.
   3. Currency: this still reproduces on server v2.0.18 (latest release). Web UI session stuck for hours with upstream invalid_request_error: no diagnostics, endless retry, no reliable recovery #45456 was closed as completed in August, so this is evidence that the replay-sanitization gap persists into the current release on the drain path / for this provider's state shape.

   Not a duplicate of #46564 — that tracks the context-overflow classification gap (opaque 400 never engages one-shot compaction recovery). In our case normal sends carrying the same full session history succeed; only the drain-path replay is rejected, so it is not an overflow misclassification.

   Not a duplicate of #49740, but complementary — that issue tracks the missing session.error surfacing for swallowed drain exceptions. Our case is another concrete instance of that silent dead-end (the client only sees repeated failures), but the cause analysis here is distinct. The retry cadence evidence (~15s, 13+ occurrences over ~7 minutes) is available for that report if useful.

   Suggest keeping this open as the drain-path + native-Mistral data point unless maintainers prefer to consolidate under #39291 — in which case the two deltas worth carrying over are the drain-resume trigger and the v2.0.18 reproduction.
4. satyalyadav commented on Oct 15, 2026

   

   satyalyadav

   on Oct 15, 2026

   More actions

   I observed the same drain-error message on OpenCode server 2.0.29 with provider/model asu/glm-5-3, variant high.

   At 2026-10-15T03:01:40.412Z, the server logged this error. Stack abridged:

   message="Failed to drain Session" cause="AI.Error: {\"error\":{\"message\":\"'str object' has no attribute 'items'\",\"type\":\"BadRequestError\",\"param\":null,\"code\":400}}"
       at SessionRunner.runStep (…)
       at SessionRunner.drain (…)
       at ServerProcess.start (…)
   

   The session metadata currently reports outcome: failed, although completed shell calls appear in the log after the error.

   I found only one matching drain-error record for this session, so I cannot confirm the repeated-retry behavior described here. This adds an occurrence with a different configured provider; it does not establish a provider-independent cause.
5. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed report. We can't reproduce this in our sandbox. The 400 comes from Mistral's GLM backend, and seeing it needs a real Mistral account with zai-glm-5-3, which we don't have here. A mocked 400 wouldn't show whether the request replayed on startup actually differs from a normal send.

   One guess, not confirmed: the Mistral integration sends tool-call arguments as a JSON-encoded copy of the stored input. If a tool call in the pending step stored its input as a plain string rather than an object, the backend would get a string where it expects an object, which would match 'str object' has no attribute 'items'.

   If you can, these would help a maintainer with Mistral access:

   • An export of the affected session, with anything private removed, mainly the last assistant message and the pending step. Check whether any tool call there has a string input rather than an object.
   • Whether you see Failed to drain Session without any further restarts, or only when the server starts or something else triggers a drain.

   Related issues:

   • Web UI session stuck for hours with upstream invalid_request_error: no diagnostics, endless retry, no reliable recovery #45456: a similar drain loop on a long session with replayed state (v1 beta, different provider)
   • compaction sends mutated thinking block -> permanent 400 retry loop #39291: a modified thinking block causing a permanent 400 retry loop
   • Failed parallel tool call leaves dangling tool_call_id, causing 400 errors on all subsequent requests #44852: a dangling tool_call_id breaking replays
   • [FEATURE]: Log LLM API request/response body at DEBUG log level #29186: request to log request and response bodies at DEBUG