Web UI session stuck for hours with upstream invalid_request_error: no diagnostics, endless retry, no reliable recovery #45456

Summary

A long-working Web UI session can get stuck for hours with every request failing:

Error from provider (Console Go): Upstream request failed:
[invalid_request_error] The request contains invalid parameters.
Check the request body for any errors or inconsistencies.

while fresh sessions with the same model/variant work fine. The upstream does not disclose WHICH parameter is invalid, opencode's logs do not include the request body, and the server keeps retrying in a ~5s loop ("Failed to drain Session"). The session eventually recovered after hours, surgical message cleanup (removing stale tool providerState / reasoning state, clearing error turns) and a revert to the last working turn — but the actual root cause is not confirmed (see below).

Environment

• opencode version: 0.0.0-beta-17963 / 18286 (reproduced on both)
• OS: Linux 7.0.0-29-generic (Ubuntu) x86_64
• Install/channel: beta
• Server: background service (Web UI), model opencode-go/muse-spark-1.2-contributor#xhigh

Reproduction

1. Run a long autonomous session (hours, millions of input tokens, many tool calls and reasoning turns)
2. At some point every send starts failing with the upstream invalid_request_error, persisting for hours
3. Restarting the server, forking, reverting, and manual message patching alone did not reliably recover it
4. The failure behavior was non-deterministic: the same revert boundary + send failed once and succeeded minutes later

Confirmed facts

• Session-specific: fresh sessions with the same model/variant work; all sessions are not affected
• The provider error has no parameter detail, and opencode server logs do not log the outgoing request body → impossible to diagnose which part of the payload the gateway rejects
• The server retries the same invalid request indefinitely (~every 5s, "Failed to drain Session"), creating log spam and keeping the session occupied
• No user-facing recovery path: fork/revert/restart alone did not restore it; the session only recovered after hours + surgical cleanup
• Side finding: POST /api/session/{id}/fork produces a session whose messages have no content at all (all parts lost) — likely a separate bug

Verification attempts (what is NOT the cause)

• Injected a real tool providerState (fc_ itemId) part (taken verbatim from the stuck session) into a healthy fresh session → request succeeds. So stale providerState item references alone do not trigger the error.
• Stripping reasoning-part state (rs_ itemIds). Patching empty/error assistant turns. Reverting to the last working user message. None of these individually produced stable recovery either.
• Conclusion: root cause is undetermined; the failure looks time-dependent / tied to transient gateway state (e.g., expired encrypted-content or item references, upstream-side limits), possibly worsened by opencode replaying old provider state without validation. This needs the request body + upstream validation detail to pin down.

Expected Behavior

• On upstream invalid_request_error, opencode should log the outgoing body / per-parameter detail so the invalid field can be identified
• Retries should not be infinite for a non-transient 4xx; surface a clear error instead
• A recovery action should exist (e.g., sanitize session history / drop stale provider state), since restart/fork/revert do not work reliably

Suggested fix direction

1. Log the outgoing provider request body (DEBUG) including on error
2. Stop / back off infinite retry on upstream 4xx invalid-request errors
3. Investigate whether replayed providerState item references and encrypted reasoning content should be stripped or refreshed when resuming old/stale turns
4. Provide a user-facing "repair session" path (strip provider state / truncate to last good turn)

Evidence

Gist (URL-restricted): https://gist.github.com/nico2525nn/80e6860b1f92aa25d0758c50b9086fb2

• broken-session-export-sanitized.json — sanitized full session export (incl. the failing error turns)
• failing-request-reconstructed.json — reconstructed model request for the failing turn (approximation; secrets redacted)
• log-excerpt.txt — server log lines showing the persistent invalid_request_error / retry loop

Related known issues

• Web UI session-state handling issues (Web UI: opening session URL directly renders blank page (no timeline) #43667 and related) — long sessions tend to break similarly
• [Feature]: add todo support for v2 #42421 — session/state handling background