fix(server): keep fork history stable across repeated source rewinds#30044

Approvability

Verdict: Approved at 86f541a

Macroscope's review found this PR approvable — This keeps fork history stable across repeated source rewinds by applying creation-time filtering consistently to history reads and counts. The change is limited to read-side selection, with no data deletion, migration, or product-default change.

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

Explain Change →

No actionable comments were generated in the recent review.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

External image Recent review info

External image Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: e455200
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 4dad1982-58ed-4d14-9670-63fb4c6c4c01

External image Commits

Reviewing files that changed from the base of the PR and between 6e0ef26257a5b6aa14b7d0325f70e3aca4d73da4 and 866ebb61ecbdb2327309882cf427247ba395ec53.

External image Files selected for processing: 2

• apps/server/src/orchestration-v2/ThreadFind.test.ts
• apps/server/src/persistence/reconcileV2PreviewMigration.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

Keeping the existing regression for the repeated-rewind case. sourceRun2Id is discarded before laterForkId is created; sourceRun3Id is completed at fork creation and discarded afterward. Its 300 items must stay inherited, while run 2's messages must stay absent. The 303-row assertions deliberately check that distinction across projection, timeline, bounded snapshot, and shell counts before and after the second rewind. This test fails on #29695 specifically after that second rewind.

The newly linked browser captures independently confirm the same behavior with real Codex Luna turns: the later fork retains alpha/charlie after rewinding charlie in the source, and the earlier control fork retains alpha/bravo. The head remains 86f541a177; only verification evidence was added to the PR description.

Verified in a real dev environment

verified unchanged head 2365fd50c9bcfd620f7e6ca0b095ca53f335225c on linux using the dev web client, repository playwright, /usr/bin/google-chrome, and real codex gpt-6.1-sol turns through the local proxy. projects, git repositories, threads, forks, and turns were created through the app. no mocks or fixtures.

• reproduced on github/main (cefb544af3) in a separate worktree: send alpha/bravo, fork a control, rewind bravo, send charlie, fork again, rewind charlie. the later fork resurrected bravo; its first provider continuation recalled only alpha.
• on this head, the later fork contains alpha/charlie before and after the second source rewind and reload. its first continuation, started only after that rewind, uses a context handoff and recalls exactly alpha, charlie without those tokens in the question.
• the earlier control fork keeps alpha/bravo and its first continuation recalls exactly alpha, bravo.
• restarted the dev server with copied isolated dev state. both forks persist, source contains only alpha, and another real turn in the later fork still returns alpha, charlie.

authenticated runtime transcript after restart:

blacksmith checks passed: the four focused fork/projection/history suites (90 tests), and vp run check:changed github/main (format, lint, knip, graphql, affected typechecks, 127 tests). no code changes were needed.

before on main: the fork resurrects discarded bravo

after on the pr: the fork keeps alpha and charlie after both source rewinds

real codex continuation after the second source rewind recalls alpha and charlie

Not verified

native electron, ios/android, other providers, and remote/relay/tunnel connections were not exercised on this linux web pass. cancelled queued prompts were covered by the existing focused tests, not a real-provider queue scenario. caller-supplied clock skew and equal-millisecond fork/rewind ordering raised in the discussion were not exercised; this pass proves the sequential web-client flow.