Thread AbortSignal through host waits and polling paths

[ThomasK33]

Problem

Several host-side waits and polling loops use raw setInterval / setTimeout without a shared cancellation contract. This makes timeout, shutdown, and future interruption behavior harder to reason about, especially around renderer waits, idle polling, and run-completion observation.

Known areas to inspect:

• src/host/hostMain.ts idle-timeout polling.
• src/host/hostMain.ts wait/render polling flows.
• src/host/runCompletionSentinel.ts polling and completion observation.
• RPC paths that wait on host/renderer work.

Context

The resource-cleanup refactor in #83 introduces a small ResourceScope helper for deterministic release. Cancellation work should integrate with that release model rather than adding parallel ad hoc cleanup paths.

Out of scope

• Adopting Effect or another async runtime.
• Rewriting CLI error handling.
• Changing public JSON envelopes or protocol schemas.
• Reworking OS signal handling unless required for the minimal AbortSignal path.

Acceptance criteria

• Relevant host wait/poll operations accept or derive an AbortSignal.
• Aborted operations release registered resources and timers deterministically.
• Non-aborted callers retain current behavior.
• Add at least one targeted test proving abort behavior for a host wait or polling path.
• Full CI passes.

---

Generated with mux • Model: anthropic:claude-opus-4-7 • Thinking: max

[ThomasK33]

This was generated by AI during triage.

Triage Assessment

Category: enhancement
State: ready-for-agent

The issue is well-specified by a project contributor with clear problem statement, acceptance criteria, and explicit scope boundaries. Codebase exploration confirms every area mentioned uses raw setInterval/setTimeout without AbortSignal support. The prerequisite ResourceScope helper from #83 is already merged and available.

Agent Brief

Category: enhancement
Summary: Thread AbortSignal through host-side waits and polling loops so they integrate with the ResourceScope cleanup model instead of using ad hoc clearInterval/clearTimeout callbacks.

Current behavior:
Host-side polling and wait operations use raw setInterval/setTimeout with manual cleanup callbacks (clearWaitCondition, clearWaitPoll, clearIdleTimeout). There is no shared cancellation contract; each call site manages its own teardown via closure-captured handles. The ResourceScope helper exists for deterministic resource release but is not yet wired into these timer/polling paths.

Key areas with this pattern:

• Idle-timeout polling: setInterval loop checking elapsed idle time, cleared via clearIdleTimeout callback.
• Wait command idle polling: setInterval inside a Promise, cleared via clearWaitCondition callback.
• WaitForRender polling: setInterval with async renderer backend calls, cleared via clearWaitPoll callback. Inflight backend requests have no cancellation path.
• Run completion waiting: setTimeout with manual resolved flag and clearTimeout.
• Lifecycle destroy polling: for loops with delay() from node:timers/promises, no early-exit signal.
• RPC socket liveness probe: net.connect() with no timeout or signal.

Desired behavior:
Relevant host wait and poll operations accept or derive an AbortSignal. When the signal fires, registered resources and timers are released deterministically. Non-aborted callers retain current behavior. The cancellation model should integrate with ResourceScope rather than introducing parallel cleanup paths.

Node's node:timers/promises already supports AbortSignal natively: setTimeout(ms, value, { signal }) and setInterval(ms, { signal }) both accept an options bag. The delay() helper (re-exported from node:timers/promises) also supports { signal }. These built-in primitives should be preferred over manual clearTimeout/clearInterval wrappers.

Key interfaces:

• ResourceScope (from refactor: extract ResourceScope and KeyedSerializer helpers #83), the deterministic release helper. Timer and signal cleanup should be registered via scope.add() so scope.close() tears everything down.
• AbortSignal / AbortController (built-in), the standard cancellation primitive. Operations should accept an optional signal parameter. Internal controllers can be derived for sub-operations.
• hostMain idle polling: the startIdlePolling() closure should accept a signal; aborting clears the interval and skips the pty.kill() path.
• hostMain wait/waitForRender handlers: the RPC handler implementations should accept a signal derived from the session or request scope. Aborting cancels the polling interval, any inflight renderer requests, and the timeout.
• RunCompletionCoordinator.#waitForRunCompletion(): should accept a signal that races with the existing timeout.
• lifecycle.ts waitForTerminalManifest() and waitForProcessAndSocketShutdown(): should accept a signal; the delay() calls can pass it directly via { signal }.
• probeSocketLiveness(): should accept a signal or at minimum a timeout to avoid hanging indefinitely.

Acceptance criteria:

• Relevant host wait/poll operations accept or derive an AbortSignal
• Aborted operations release registered resources and timers deterministically (via ResourceScope or equivalent)
• Non-aborted callers retain current behavior (no regressions)
• At least one targeted test proving abort behavior for a host wait or polling path
• Full CI passes

Out of scope:

• Adopting Effect or another async runtime
• Rewriting CLI error handling
• Changing public JSON envelopes or protocol schemas
• Reworking OS signal handling unless required for the minimal AbortSignal path
• Renderer-side timer cleanup (this issue targets host-side only)