[Bug]: A fresh-session schedule stops dispatching for good once a previous run's session still has background work #32100

Before submitting

• I searched existing issues and did not find a duplicate. (Closest: [Bug]: A scheduled run that fails is recorded as succeeded #17889, a failed run recorded as succeeded.)
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Create an interval schedule (every 15 min) with freshSession: true and no bound thread, so every run reuses one thread with a fresh Claude session.
2. In one run, have the agent start a background command (run_in_background) that finishes after the turn ends. In our case the run itself failed at 16:05:23 UTC; its background command completed afterwards.
3. The completion notice is queued on the thread as a new run (ordinal:23, requested 16:05:05) and never starts. The run's claude process stays alive.
4. Wait for the next scheduled run, or call run_scheduled_task_now.

Expected behavior

The next run starts a new session, since the schedule asks for a fresh session per run. Or the old session's leftover background work is cancelled or delivered so it doesn't block. If a run can't be dispatched, the error says why.

Actual behavior

Every later dispatch fails with OrchestratorDispatchError: Failed to dispatch orchestration command message.dispatch (scheduled-task:…). In the trace it fails right after Orchestrator.sessionHasBackgroundWork. The schedule records lastRunStatus: failed, and run_scheduled_task_now returns threadId: null. This continues indefinitely: the Slack schedule recorded nothing from 16:05 to 16:20 UTC, and we stopped it only by hand.

None of these unblocked it:

• cancelling the queued notice run (t3_queue cancel)
• t3_thread_interrupt with stop: true, which returned no_active_run
• killing the session's claude process

orchestration_v2_projection_provider_sessions still lists one session per earlier run for that thread with status ready (17 rows), although their processes are gone.

Impact

Major degradation or frequent failure

Version or commit

0.1.8-nightly.20261106.4262

Environment

Ubuntu 24.04 on EC2 (t3.large), T3 as a systemd user service, headless. Claude provider (Claude Code 2.1.318) through a local proxy, model claude-opus-5-5, runtime full-access.

Logs or stack traces

Orchestrator.sessionHasBackgroundWork Success
Orchestrator.dispatchMessage Failure OrchestratorDispatchError: Failed to dispatch orchestration command message.dispatch (scheduled-task:scheduled-task:6740bb40-…:1793981951042:manual).
    at Orchestrator.dispatchMessage (…/t3:371206:38)
orchestrationV2.dispatch.withReceipt Failure OrchestratorDispatchError: …
    at ThreadManagementService.sendToThread (…/t3:380362:74)
    at ScheduledTaskService.runTask (…/t3:380726:18)
    at ScheduledTaskService.runNow (…)

Workaround

Delete the schedule and create it again, which gives it a new thread. Running every scheduled run in its own thread (freshSession: false, unbound) avoids it, because a stuck session then blocks only its own thread. Restarting T3 probably clears it too, but that kills every other running thread.