fix(server): retrying a new thread's first send no longer fails with "already exists"

[pc-style]

Sending the first message on a new thread could fail during worktree prep. After that, every retry from the same draft errored with "Thread ... already exists and cannot be created twice", forever. The cleanup's thread.delete is a soft delete, and requireThreadAbsent counted the soft-deleted row as still occupying the id, which draft threads keep across retries.

The decider now treats a soft-deleted thread as absent, so the retry re-creates the id. The projection pipeline also purges the old incarnation's dependent rows on re-create, so the thread starts clean. Tests cover the invariant, a create/delete/re-create decider round-trip, and an engine-dispatch check that the purge runs.

Proof of work

Backend-only change (apps/server), no UI surface, so no screenshots.

• vp test run on the three touched test files: 3 files, 30 tests, all pass
• tsgo --noEmit in apps/server: clean
• vp lint on the five touched files: clean

Written by Claude Fable 5 via Claude Code.

---

Note

Medium Risk
Changes orchestration invariants and multi-projector thread lifecycle behavior; scoped to soft-delete/re-create paths with solid test coverage.

Overview
Fixes first-send retries on new drafts that reuse the same client-generated thread id after a failed attempt triggers cleanup via soft thread.delete.

Command invariants: requireThreadAbsent now treats threads with deletedAt set as absent, so thread.create with the same id is allowed instead of failing with "already exists".

Projections: On thread.created, dependent projectors purge prior rows for that thread id (messages, turns, activities, proposed plans, sessions, pending approvals). The threads projector still upserts a fresh shell with deletedAt: null. That keeps live dispatch and per-projector replay (threads projector runs last) aligned with the new incarnation.

Tests cover the invariant, decider delete→recreate, engine dispatch purge, and bootstrap replay.

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

Note

Fix retry of new thread's first send failing with "already exists" after deletion

• requireThreadAbsent in commandInvariants.ts now treats a thread as absent if it is soft-deleted (deletedAt !== null), allowing re-creation with the same id
• Every projector in ProjectionPipeline.ts (messages, turns, sessions, activities, proposed plans, pending approvals) purges all existing rows for the thread on thread.created, so stale projections from a prior incarnation don't conflict
• ThreadDeletionReactor in ThreadDeletionReactor.ts skips provider session stop and terminal close when the thread id has already been re-created and is live
• Behavioral Change: a soft-deleted thread id can now be re-used immediately; the thread.created event now performs destructive deletes across all projection tables for that threadId before re-inserting

^{Macroscope summarized a27f2b0.}

[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: af55f9d4-9aaf-4606-8be3-9f5d6b3631af

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

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[SunkenInTime]

Taking a look at this

[Osman-bin-nasir]

LGTM!

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This bug fix enables thread ID reuse after deletion by purging old projection data on thread recreation. While the changes are well-scoped and heavily tested, an unresolved Medium severity finding about error handling in the deletion reactor warrants human review.

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

[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.}

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

[shivamhwp]

sol on behalf of shivamhwp

Thanks for the work here. We reproduced the exact failure this PR targets. After a failed first-send bootstrap, retrying reused a deleted thread ID and hit thread.create ... already exists and cannot be created twice.

#7664 fixes that same path and has now merged. We verified it through the real web app. After the initial bootstrap failure, the retry minted a fresh thread ID and reached the original Git failure again instead of the invariant error.

We are closing this as superseded because #7608 fixes the symptom by allowing a soft-deleted ThreadId to be created again. That changes the event identity rule, adds projection cleanup work to every thread.created, and leaves a race where old deletion cleanup can target resources from the recreated thread lifetime. #7664 avoids those risks by keeping the draft and assigning each bootstrap attempt a new ThreadId.

Thank you for digging into this and for the test coverage.