fix(server): a draft can retry its first send after a failed bootstrap

[shivamhwp]

Sending the first message on a new thread bootstraps thread.create and thread.turn.start together. When the bootstrap fails partway (worktree prep on a repo with no commits, a setup script, a dropped connection), the server rolls back with thread.delete. That is a soft delete, and the draft keeps its client-minted thread id, so the retry's thread.create hit requireThreadAbsent and was refused with "Thread already exists and cannot be created twice", on every retry, until the draft was abandoned. #7664 rotates the id on the client when the server reports the deletion, which covers the common path but not an interrupted send or a failed cleanup.

requireThreadAbsent now only blocks on a live row. Each per-thread projector drops its rows for the old incarnation when it applies thread.created, so a re-created id starts with an empty timeline and per-projector replay stays deterministic. A replayed thread.deleted that a later thread.created supersedes no longer removes attachment files, since those already belong to the new incarnation. Both thread.create paths in ws.ts wait for the deletion reactor to drain first, so the old incarnation's session stop and terminal close always finish before the new thread can own those resources.

Closes #4647. Closes #5721.

Verification: server suites 452/452, typecheck, lint. Each new test fails with its fix reverted. Live app with client id rotation disabled: nine same-id retries against a repo with no commits, zero invariant errors, clean projection. Full report with screenshots: https://y5pnrxd87iej.postplan.dev

Out of scope, noted for follow-up: the provider resume cursor and checkpoint git refs are not cleaned on delete (pre-existing, unreachable from this path since the failed incarnation never starts a turn). The same stale-child-rows hole exists in orchestrator V2's ON CONFLICT DO UPDATE on thread.created.

Claude Fable 5 via Claude Code.

Note

Allow draft to retry first send after failed bootstrap by re-creating soft-deleted threads

• requireThreadAbsent in commandInvariants.ts now treats soft-deleted threads as absent, so thread.create succeeds for an id whose previous incarnation was deleted.
• WebSocket handling in ws.ts fences on thread.create: after dispatching a create, it calls threadDeletionReactor.drainThrough(created.sequence) and waits for the reactor to observe events up to that sequence and drain its worker before proceeding with bootstrap setup or returning.
• ThreadDeletionReactor API changes from drain to drainThrough(sequence) in ThreadDeletionReactor.ts, using a SubscriptionRef watermark to track the highest observed event sequence.
• Projections in ProjectionPipeline.ts now clear all per-thread rows on thread.created (messages, sessions, turns, activities, proposed plans, pending approvals) and only schedule attachment deletion for thread.deleted when hasEventAfter confirms no later thread.created exists for the same aggregate.
• Event store in OrchestrationEventStore.ts gains hasEventAfter to check whether an event of a given type exists after a supplied sequence for an aggregate.
• Risk: ThreadDeletionReactorShape and OrchestrationEventStoreShape interfaces changed — any out-of-tree implementations must now provide drainThrough(sequence) and hasEventAfter(input) respectively.

^{Macroscope summarized e6b5f34.}

---

Note

Medium Risk
Changes thread lifecycle invariants, projection replay semantics, and deletion-cleanup ordering; behavior is well covered by new tests but affects core orchestration paths.

Overview
Fixes failed first-send bootstrap where thread.delete left a soft-deleted row and blocked retries with “Thread already exists.” requireThreadAbsent now only rejects when the thread is still live (deletedAt is null).

Projection replay treats a reused id as a new incarnation: on thread.created, per-thread projectors wipe messages, turns, sessions, activities, plans, and pending approvals for that id. On replayed thread.deleted, attachment cleanup runs only when eventStore.hasEventAfter finds no later thread.created for the same aggregate, so retried threads keep on-disk files.

ThreadDeletionReactor replaces drain with drainThrough(sequence), tracking the highest seen event sequence and waiting until the subscriber has caught up before draining the cleanup worker. ws.ts calls drainThrough after every successful thread.create (including bootstrap) so prior deletion cleanup (sessions/terminals) finishes before the new incarnation owns those resources.

^{Reviewed by Cursor Bugbot for commit e6b5f34. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 997b3e27-051c-4fa3-adbb-b20577141519

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

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

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This fix changes core thread lifecycle and replay semantics across projections, persistence, cleanup workers, and WebSocket sequencing. The behavior is well tested, but the cross-cutting runtime coordination and new cleanup fencing are substantial enough to merit human review.

^{You can add or adjust custom eligibility rules. Learn more.}