Uh oh!
There was an error while loading. Please reload this page.
fix(desktop): stop replaying session remove after a restore - #3068
fix(desktop): stop replaying session remove after a restore#30681625567290 wants to merge 1 commit into
Conversation
A revision conflict on session.remove means the task changed after the caller decided to destroy it. If the first read was archived and the re-read is not, return restored instead of deleting at the new revision. purgeSessions counts that separately from a failure. Fixesapache#3050 Generated-by: Grok
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
📝 WalkthroughSummaryThis PR prevents desktop session removal from deleting a session after a concurrent restore. After a revision conflict, The change extends the existing removal path. It does not create a parallel removal mechanism. The This is the smallest coherent solution because each layer must preserve the outcome. The new result type and No code or tests can be safely deleted based on the supplied changes. The updated mocks and focused assertions preserve the existing removal contract and regression coverage. Risks and validation
Focused tests cover archived removal, same-lifecycle retries, concurrent restores, active-session renames, purge reporting, and related session actions. Biome checks passed on touched files. Full workspace checks were not run because WalkthroughThe session removal flow now detects concurrent restoration and returns distinct ChangesSession removal outcomes
Estimated code review effort: 3 (Moderate) | ~25 minutes Merge Risk:⚪ Minimal · up to The change prevents a concurrently restored archived session from being deleted during retry while preserving active-session rename retries; no actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant Renderer
participant IPC
participant DesktopRuntimeHostClient
Renderer->>IPC: sessions.remove(sessionId)
IPC->>DesktopRuntimeHostClient: removeSession(sessionId)
DesktopRuntimeHostClient-->>IPC: removed or restored
alt removed
IPC-->>Renderer: { kind: 'removed' }
Renderer->>Renderer: retire resources and update purge counts
else restored
IPC-->>Renderer: { kind: 'restored' }
Renderer->>Renderer: retain session and increment restored count
end
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
1625567290
commented
Aug 15, 2026
Closing in favor of #3056, which already covers the same |
Summary
removeSessiontreated arevision_conflictas a stale read and retried the delete with the new revision. A concurrent restore (second window) bumps the revision and unarchives the task, so the retry permanently deleted it.If the first catalog read was archived and a later read is not, the loop now returns
restoredand does not callsession.removeagain. An active-session delete still retries after a rename.purgeSessionscountsrestoredseparately from a failure.Fixes#3050
Verification
npx tsx --teston:runtime-host-client-operations.test.ts— including first-try remove, archived retry, restore-after-conflict, and active rename retryapp-shell-session-purge.test.ts— 7/7, including Host-side restore counted separatelyapp-shell-session-row-actions-revisions.test.tsapp-shell-first-send-cleanup.test.tsbiome checkon the touched files — cleanNot run:
tsc -p tsconfig.main.jsonon thismainfails inshell-copy.ts(archived-tasksmissing from a settings-section record). That file is outside this change.Checklist
Does this PR entail a change in behavior?