feat(mcp): defer thread organization safely#8683

🟠 High orchestration-v2/Orchestrator.ts:2111

Deferred thread.organization.defer.apply leaves provider sessions and background work alive after applying settle or archive, and deferred archives retain MCP credentials. These branches emit terminal thread events directly instead of using the teardown logic in dispatchThreadMutation, so they omit provider-session.detached, provider-session.detach, revokeMcpCredential, and terminal.cleanup effects. Route deferred application through the same teardown path as ordinary archive/settle, or emit the equivalent events and effects.

✅ Resolved in d76789f408aaf8c8ee7ef2d2f801528f2f2565db

Fixed in acb2b17f3c. Deferred apply now delegates to the ordinary serialized thread settle/archive mutation with an atomic clear-intent option, inheriting provider detach, archive credential revocation, terminal cleanup, and delegated-completion disposal. Focused coverage opens a real managed provider session, drains the effect worker, verifies terminal effect settlement, and proves receipt replay enqueues no second cleanup.

The new deferred-organization startup recovery only catches at the outer Effect.forEach, so a single thread whose projection load or dispatch fails aborts the whole pass and leaves later threads' intents unrecovered. Consider isolating the failure per entity, as the neighbouring subagent and delegated-completion recovery passes do (each wraps the per-thread withLock in its own Effect.catchCause before the outer catch).

A focused test that one persistently failing thread does not prevent a second thread's intent from being applied would lock this in.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in acb2b17f3c. Deferred recovery is now a typed post-provider-reconciliation startup hook, and each thread lock/projection/apply path catches independently. The persistent-failure integration corrupts one thread projection and verifies the next deferred intent is still recovered.

orchestration-v2/Orchestrator.ts:7274

This startup reconciliation repairs many independent threads, but a per-thread failure is not isolated: Effect.forEach fails fast (and interrupts the other in-flight fibers at concurrency: 8), so one bad thread aborts recovery for every remaining deferred intent, and the outer catchCause then reduces it — including interruption — to a single warning. The two neighbouring recovery loops below (app-owned subagents, delegated completion delivery) already wrap the per-thread effect in its own catchCause. Consider adding a transient retry plus per-thread isolation here as well, and covering both the retry-success and persistent-failure-continuation paths in DeferredOrganizationRecovery.integration.test.ts (it currently only asserts the stale-discard path).

No longer relevant as of acb2b17f3cc66a207d81763e9e70c7b2926f7978

Fixed in acb2b17f3c with per-thread isolation and focused persistent-failure continuation coverage. I did not add a broad retry: a durable unreadable projection is not made recoverable by immediate retries, while independent intents can continue safely.

orchestration-v2/Orchestrator.ts:7281

Per-thread isolation is fixed now, but this reconciliation still reduces interruption to a warning and never retries a transient repair before readiness. Effect.catchCause catches interrupt causes too, so a shutdown mid-recovery keeps sweeping the remaining threads instead of unwinding; and a one-off projection/dispatch failure permanently skips that thread's intent until the next restart. Consider retrying briefly, then re-failing interrupt-only causes before falling back to the warning, and covering the retry-success path next to the existing persistent-failure continuation test.

Needs import * as Cause from "effect/Cause" and import * as Schedule from "effect/Schedule".

No longer relevant as of afd33efd2d8cd684b11cc34b7c8edcee3e80e083

Fixed in afd33efd2d8cd684b11cc34b7c8edcee3e80e083. The recovery wrapper retries only ProjectionStoreReadError and OrchestratorDispatchError once, immediately. It does not retry rejected receipts, defects, or other causes. Cause.hasInterruptsOnly now propagates so shutdown unwinds; persistent non-interrupt failures keep the prior warning-and-continue behavior. The focused test proves exactly two attempts for one transient typed read failure and separately observes an interrupt-only exit, without timers or polling.

🟡 Medium orchestration-v2/Orchestrator.ts:107

A transient projection read failure during deferred apply is recorded as a rejected deterministic command, and later recovery replays that rejection instead of applying or clearing the persisted deferred intent. dispatchDeferredOrganization maps the read failure to OrchestratorProjectionError, which is excluded from the while predicate; include that error type in the retry condition so the apply is retried before its receipt is permanently rejected.

Fixed in 284b9dca6933303a56fe7ce10748847444cfe2e7 at the earlier boundary. thread.organization.defer.apply retries one typed projection failure around the pure plan, before commitRejectedCommand. The real receipt-store test fails that planner read once, then proves the deterministic receipt is accepted and the intent clears.

🟡 Medium user/thread-sidebar.md:30

A message sent while the provider supports active steering does not keep the thread visible: the client selects steer_active, dispatchSteerIntoRun appends it to the current run, and dispatchDeferredOrganization later settles or archives that same thread because no newer run exists. The documentation should limit this behavior to messages that create a newer run.

Fixed in 284b9dca6933303a56fe7ce10748847444cfe2e7. The documentation now limits invalidation to a message that creates a newer run; steer_active remains part of the current run.

🟡 Medium src/orchestrationV2.ts:2172

Any connected client can submit thread.organization.defer.apply and prematurely clear deferredOrganization while the bound run is still active, cancelling a pending settle/archive request before its terminal path. Because this variant is part of the public OrchestrationV2Command union, dispatchCommand forwards it to dispatchDeferredOrganization, which reaches !canApply; keep this command in a server-internal schema rather than the client-facing union.

Fixed in 71650ee5adf1ac035cd4f30d607ea5bf77bbba21. The public orchestration.dispatchCommand schema rejects only thread.organization.defer.apply; the full internal command schema and server dispatch path still accept it, and defer.cancel remains public. Contract coverage decodes those three boundaries explicitly.

Apply failure skips queued run promotion

Medium Severity

applyDeferredOrganization now runs on the same terminal-run fiber as startNextQueuedRun. A failed projection read or apply dispatch fails that fiber, so the shared handler only logs and never promotes the next queued run. Follow-up work on that thread then sits queued until a later restart.

^{Reviewed by Cursor Bugbot for commit cf20d21001108280d379a5db99b02d5c6d87d704. Configure here.}

Fixed in 71650ee5adf1ac035cd4f30d607ea5bf77bbba21. Terminal handling now isolates a typed deferred-apply failure before startNextQueuedRun, while interrupt-only causes still propagate. The real SQLite/EventSink/ProjectionStore test fails the apply read, observes the queued run become starting, and confirms the stable apply receipt ID was not consumed.