fix(server): threads swept by old desktop builds show their real settled time again

[shivamhwp]

Problem

Desktop builds 0.0.35 to 0.0.38 settled idle threads from the client in one burst and stamped each thread's settled time with the sweep time instead of its last activity. Those threads still sit in the sidebar's Settled section with the wrong age, bunched together as if they were all closed at the same moment. Migration 046 repaired the server-attributed version of this, but it skips client-attributed events on purpose, so these were never fixed. The V1 to V2 import then copied the bad values into V2 (#10937).

Change

New migration 060 finds the client-attributed sweeps and puts the real last-activity time back:

• Candidates: thread.settled V1 events with actor_kind = 'client', an app version from 0.0.35 to 0.0.38, before 2026-09-05, where the event's settledAt equals its occurred_at (the sweep's stamp).
• A sweep is 10 or more distinct threads whose events are each no more than 30s apart, within two minutes overall. Grouping by the gap between events, rather than "anything within two minutes", keeps a later manual settle from getting pulled into the sweep. That was the review finding on the earlier attempt.
• It repairs both places the value lives: V1 projection_threads.settled_at for threads not imported yet, and settledAt inside orchestration_v2_projection_threads.payload_json for threads already imported into V2.
• Event history is untouched. A second run changes nothing.

This rebuilds #10975 by @Gigioxx on current main, which has one migration chain for V1 and V2. 059 is the last migration on main.

Scope and approval

Closes #10937. The issue is triaged and accepted. Julius's triage confirmed the gap in 046 and the discriminators used here: client actor, the affected app versions, the cutoff date, and a dense burst.

Verification

There's no new UI. The bug is old data in existing databases, so the evidence is the migration test run against both branches. The test seeds a 12-thread client sweep plus the cases that must not change, then runs every migration.

Before (main 1e2ecbd, with the new test file copied in): the swept thread keeps the sweep time. expected '2026-09-04T13:33:00.000Z' to equal '2026-04-01T00:00:00.000Z'.

10975-before.mp4

After (this PR): passes.

10975-after.mp4

vp test run apps/server/src/persistence/Migrations/060_RepairClientSettlementTimestamps.test.ts covers:

• the 12-thread sweep, on both the V1 and the already-imported V2 rows
• a manual settle 45s after the sweep, which stays as it was
• a cohort smaller than 10 threads
• one thread settled 10 times
• a cohort spread over more than two minutes
• the wrong app version, missing version metadata, and events after the cutoff
• running the migration again, and event history staying unchanged

The neighboring migration tests (046, 054, 055, 056, 057) and the V2 preview upgrade test pass. 055_OrchestrationV2.test.ts changes only because it lists the migrations by count. Scoped tsc and lint are clean.

Not checked: a real database from an affected 0.0.35 to 0.0.38 install. An independent review also replayed the original audit fixture through this migration (57 before the renumber) and saw every swept thread repaired.

Made with Claude Opus 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a startup migration that uses non-trivial burst heuristics to rewrite settled timestamps across both V1 and V2 projections. Although the scope is targeted and well tested, the complexity and persisted-data impact warrant human review.

^{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	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	20.9 KiB	20.9 KiB	0 B (0.0%)	29.3 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	−24 B (−0.5%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	−24 B (−2.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.2 KiB	21.2 KiB	−41 B (−0.2%)	29.3 KiB	✅
Claude	Live turn messages	2	1	−1 (−50.0%)	8	✅

Baseline: d720210 · PR result: 3413260 · 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: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

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

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: 80b82a95-e5e8-48a0-9ca1-0b2d8881a56b

📥 Commits

Reviewing files that changed from the base of the PR and between 5fe5cf4 and 3413260.

📒 Files selected for processing (5)

• apps/server/src/persistence/Migrations.ts
• apps/server/src/persistence/Migrations/055_OrchestrationV2.test.ts
• apps/server/src/persistence/Migrations/060_RepairClientSettlementTimestamps.test.ts
• apps/server/src/persistence/Migrations/060_RepairClientSettlementTimestamps.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.

---

📝 Walkthrough

Walkthrough

Migration 60 repairs qualifying client-attributed settlement timestamps in the V1 and V2 thread projections. It is registered in the migration runner, and migration tests cover repair criteria, unchanged cases, and upgrade ordering.

Changes

Settlement timestamp repair

Layer / File(s)	Summary
Detect bursts and repair projections apps/server/src/persistence/Migrations/060_RepairClientSettlementTimestamps.ts, apps/server/src/persistence/Migrations/060_RepairClientSettlementTimestamps.test.ts	The migration identifies client-attributed settlement bursts that meet its version, date, event-gap, thread-count, and span criteria. It updates matching settled timestamps in both projections using the latest prior activity, or creation time when no prior activity exists. The integration test checks qualifying and excluded cases, event-history preservation, and repeat-run behavior.
Register and validate migration 60 apps/server/src/persistence/Migrations.ts, apps/server/src/persistence/Migrations/055_OrchestrationV2.test.ts, apps/server/src/persistence/reconcileV2PreviewMigration.test.ts	The migration runner registers migration 60. Upgrade tests include it in the migration sequence and persisted migration records, including preview-upgrade and retry cases.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to 34132

This change repairs historical settlement timestamps in both thread projections and leaves event history untouched. Tests cover the selection criteria and rerun safety, and no concrete merge-blocking risk was identified.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 34132

The repair narrowly targets historical settlement timestamps and preserves recorded events. No new public access path was identified, but interruption and concurrent-retry behavior for the two-step repair was not fully established.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• observed — Candidate grouping is database-wide rather than project-scoped. The writable outcome is limited to settlement timestamps in qualifying thread projection rows, with each update correlated to that row’s thread ID and existing settlement timestamp.

Trust Boundaries and Controls

• observed — Client-attributed historical event fields influence repair eligibility, but they are read as stored data by static migration-owned SQL, not interpreted as SQL or supplied through a new request entrypoint. Both sinks retain settled-state, thread-identity, and timestamp-match controls.

Resilience and Maintainability Implications

• observed — The existing SQLite client acquires a transaction connection permit with finalizer-based release and uses BEGIN IMMEDIATE for writable connections. These are existing locking and cleanup controls, not direct proof that both repair statements and migration-ledger recording share one atomic transaction. The inspected rollback test exercises a separate preview-reconciliation transaction.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Migration 060 satisfies the coding requirements in #10937. It selects client-attributed thread.settled events from app versions 0.0.35–0.0.38 with matching settledAt and event timestamps before th…
Out of Scope Changes check	✅ Passed	The changes stay within #10937. Migration registration and migration-sequence test updates enable and verify the repair. The new integration test verifies the migration and its safety conditions. No u…
Title check	✅ Passed	The title clearly identifies the server fix for incorrect settled times caused by older desktop builds and follows the repository's conventional commit style.
Description check	✅ Passed	The description includes the required Problem, Change, Scope and approval, and Verification sections. It explains the affected data, migration behavior, issue reference, test coverage, observed result…

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

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

---

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