Session run defects are silently dropped — UI shows no error, session just goes idle #42251

Title: Session run defects are silently dropped — UI shows no error, session just goes idle

Problem

When a session run fails with an unexpected defect (e.g. a tool-load failure, a resolver error, a provider bug), no error is surfaced in the UI at all. The session transitions to idle as if it succeeded — the user gets no error message, nothing to indicate the run failed.

Repro

1. Set up a project whose tool load fails (a .opencode/tool/broken.ts importing a nonexistent package).
2. In the web UI, open a session in that project and send any prompt.
3. Observed (before fix): the assistant turn ends, the session goes idle, and no error is shown — the real ResolveMessage never appears anywhere in the UI.

(With opencode run in a terminal the failure does surface, but only as the generic masked fallback Unexpected server error. Check server logs for details. — the real cause is still lost.)

Root cause

The session.error event is published after the session.status idle event, so UI consumers that stop processing on idle never render it.

packages/opencode/src/effect/runner.ts — finishRun (line ~70) publishes the session's idle status (via the onIdle hook → session.status idle) before completing the run's Deferred. The failure then propagates out of ensureRunning to the HTTP handler, whose catchCause publishes session.error. The SSE ordering is therefore always:

session.status busy → session.status idle → session.error   (error arrives too late)

Clients that stop consuming on idle never see the error, and the web session renderer marks the turn complete when idle arrives — so the error is never displayed.

Expected

The real error message must reach the UI. The session.error event should be published before the idle status so consumers that stop on idle still receive and render it.

Notes

• I hit this using headless opencode via the web browser (the opencode serve API driven from a browser session); I did not test or investigate the TUI.
• Related to the companion issue about tool files that fail to load: the broken-tool repro is the easiest way to trigger this, but this issue covers any unexpected session-run defect.
• The masking boundary lives in packages/opencode/src/server/routes/instance/httpapi/middleware/error.ts (defect-only 500s → NamedError.Unknown with ref); the core problem here is ordering, not just the mask.