[BUG] Queued SessionPrompt.loop() callers can hang forever on cancel/dispose

[neriousy]

Description

When a session is already busy, SessionPrompt.loop() returns a Promise and pushes its { resolve, reject } handlers into state()[sessionID].callbacks. If the session is cancelled (or the instance is disposed) while callbacks are queued, we abort/delete state but never reject those queued promises. Concurrent callers can wait forever.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[ESRE-dev]

This should be resolved by the upstream Effect/Runner migration.

c5442d418d — refactor(session): effectify SessionPrompt service (#19483) (Mar 30) introduces a Runner state machine that replaces the old SessionPrompt.loop() queueing. The Runner uses SynchronizedRef-based atomic state transitions with four states: Idle, Running, Shell, ShellThenRun.

Key changes relevant to this issue:

• Concurrent loop() callers coalesce — Runner.ensureRunning returns the same Deferred to all callers when a run is already in progress. No more queueing or hanging.
• Cancel interrupts the fiber — Runner.cancel does Fiber.interrupt, which propagates through Deferred.await in Permission/Question services. Pending waits are interrupted, not left dangling.
• Runner.Cancelled error — interrupted callers get a typed Cancelled error instead of hanging indefinitely.
• Scope finalization — addFinalizer on Permission/Question state rejects all pending deferreds on scope close.

We had a PR (#20102) targeting this with a different approach (generation-guarded cancel, precancelled map, explicit rejectSession()), but it was obsoleted by this architectural change before it could be merged. Closed it with details in the PR comment.

cc #20095 (related issue, now closed)