fix(server): capture checkpoints before refreshing PR status

[t3dotgg]

CheckpointReactor ran the git status refresh on the same worker as checkpoint capture, and before it. That refresh ends in a remote PR lookup under the vcs status write lock. A fast follow-up message could edit files before the capture committed, so the checkpoint recorded the wrong tree.

The refresh now runs on its own drainable worker (statusRefreshWorker). Turn completion enqueues the refresh and moves straight to capture, so capture never waits behind the network call and checkpoints for other threads do not queue behind it either. drain waits on both workers. One test pins the behavior: the PR refresh blocks on a Deferred that stays open until the checkpoint.diff.finalized receipt lands and the ref contains the edited file.

Extracted from #10297.

Written by Claude Fable 5.1 in Claude Code.

Note

Decouple local git status refresh from checkpoint capture in CheckpointReactor

• Completion events in CheckpointReactor.ts now enqueue status refresh work on a separate drainable worker instead of awaiting it inline, so checkpoint processing can proceed while the refresh is pending
• The reactor drain operation now waits for both the main worker and the new status-refresh worker
• Non-interruption failures in the status-refresh worker are logged and swallowed; only interruption causes propagate
• Adds test coverage in CheckpointReactor.test.ts for capturing a turn's checkpoint while pull-request status lookup is still pending
• Behavioral Change: CheckpointReactor.make drain now blocks on queued status refreshes; callers relying on drain completing without pending refresh work will see different timing

^{Macroscope summarized 5d98a6c.}

[macroscopeapp]

Approvability

Verdict: Approved at 5d98a6c

Macroscope's review found this PR approvable — This is a focused server bug fix that isolates slow PR status refreshes from checkpoint capture while preserving worker draining and error handling. The added test directly covers checkpoint capture during a pending PR lookup, with no broader API, deployment, security, or configuration impact.

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

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.6 KiB	13.6 KiB	+12 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	7.0 KiB	7.0 KiB	−1 B (−0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.5 KiB	6.6 KiB	+13 B (+0.2%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.1 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	10	10	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.5 KiB	+13 B (+0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	7.0 KiB	−8 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.5 KiB	6.5 KiB	+21 B (+0.3%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.8 KiB	57.8 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	8	8	0 (0.0%)	21	✅

Baseline: eb8ed80 · PR result: 5d98a6c · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 113.8 KiB
• Claude decoded thread snapshot: 114.5 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.