[Bug]: Stop's delegated-task cleanup blocks replacement Pi startup for 95 seconds #30653

Before submitting

• Searched recent open/all-state issue listings; no matching report found (not an exhaustive historical search).
• Included content-free evidence sufficient to investigate; no deterministic clean-upstream reproduction yet.

Area

apps/server

Steps to reproduce

Observed with a long-lived Pi orchestrator containing 34 existing direct delegation records (plus nested work): stop the parent, then submit a replacement message after the parent shows interrupted. The replacement remained starting for 94.7s despite successful Pi interruption. I have not reproduced this on a clean upstream build; a useful test would hold descendant-stop dispatches open across the existing 30s effect deadline and check replacement admission/visibility.

Expected behavior

Stop should preserve cancellation of descendant work and prevent duplicate execution, but make bounded progress and expose the cleanup dependency instead of appearing to hang in provider startup. Do not simply let replacement work bypass unfinished Stop cleanup.

Actual behavior

The durable outbox and server logs show one delegated-tasks.stop effect timing out three times, blocking later effects on the same thread. Attempt 4 succeeded, followed by checkpoint cleanup and normal provider startup.

All UTC, 2026-11-04:

04:56:33.458 provider-turn.interrupt succeeded (first attempt)
04:56:50.766 replacement requested; status starting
04:57:04.836 delegated-tasks.stop: Timed out after 30s (attempt 1)
04:57:35.194 delegated-tasks.stop: Timed out after 30s (attempt 2)
04:58:05.547 delegated-tasks.stop: Timed out after 30s (attempt 3)
04:58:13.816 delegated-tasks.stop succeeded (attempt 4)
04:58:20.586 checkpoint.capture succeeded
04:58:25.494 replacement became running
05:01:35.487 replacement completed successfully

The preceding run needed Stop because its native Codex response remained unfinished for 10h37m until abort. That native stall's trigger is unknown and is not attributed to the cleanup timeouts. This issue is about recovery after Stop.

Impact

Major degradation: a recovered provider still appears unable to start, encouraging repeated messages/restarts.

Version or commit

Locally patched 0.1.6 (8f2d90eeb8cf4d281118cfb54a4ca307442f4df8, owner-scoped GitHub credentials and Pi handled-input settlement patches). No claim of clean-upstream reproduction. The same recursive stop loop and 30s bound were checked in upstream main at e68e19d605485db6ef31b2033f67a9d07634fc2b: ThreadManagementService.stopDelegatedTasks and EffectWorker.ts's DELEGATED_TASKS_STOP_TIMEOUT.

Environment

Linux 5.15 x64, server Node runtime, Pi RPC via named specialist launcher. Shared installed Pi 1.5.0 / Bun 1.4.0; the original process has exited, so its historical executable version is inferred from the launcher, not independently captured.

Workaround

Wait for existing Stop cleanup to finish; the replacement eventually started. No T3 service restart, forced cleanup skip, or prompt replay was needed during diagnosis.

AI-assisted report prepared at the owner's request; private messages, tool arguments, credentials, and full traces intentionally omitted.