fix(sessions): sweep orphan store temp files#90503
Conversation
|
Codex review: needs maintainer review before merge. Reviewed June 30, 2026, 12:05 PM ET / 16:05 UTC. Summary PR surface: Source +53, Tests +75. Total +128 across 2 files. Reproducibility: yes. at source level. Current main creates identifiable session-store atomic temp files and has explicit stale-temp cleanup primitives, but ordinary store load does not automatically sweep them; the PR body also supplies a real checkout probe for the proposed sweep. Review metrics: 1 noteworthy metric.
Stored data model Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land the narrow load-time sweep if maintainers accept the session-state cleanup boundary, ideally sharing the existing stale-temp window with disk-budget cleanup to prevent drift. Do we have a high-confidence way to reproduce the issue? Yes, at source level. Current main creates identifiable session-store atomic temp files and has explicit stale-temp cleanup primitives, but ordinary store load does not automatically sweep them; the PR body also supplies a real checkout probe for the proposed sweep. Is this the best way to solve the issue? Yes, this is a narrow maintainable fix for the linked leak because it covers the active store path wherever the store is first loaded. Sharing the existing stale-temp cutoff would make the implementation cleaner, but no line-level correctness bug was found. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 6cb82eaab865. Label changesLabel justifications:
Evidence reviewedPR surface: Source +53, Tests +75. Total +128 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
This is green and mergeable — it sweeps orphaned atomic-write temp files at gateway startup so stale |
Co-authored-by: Sahibzada Allahyar <[email protected]>
c68ca1c to
1ec6f9c
Compare
|
Maintainer rewrite and land-ready verification complete.
Proof:
Contributor credit is preserved in the rewritten commit and PR. |
) Co-authored-by: Peter Steinberger <[email protected]>
) Co-authored-by: Peter Steinberger <[email protected]>
Fixes #89520.
What Problem This Solves
A hard-killed atomic session-store write can leave
sessions.json.<pid>.<uuid>.tmpartifacts behind indefinitely. Repeated crashes accumulate files in each agent session directory.Why This Change Was Made
The original PR scanned the session directory during uncached store reads. This maintainer rewrite moves cleanup to the existing Gateway/embedded-TUI startup migration lifecycle, so ordinary reads stay free of directory I/O.
The startup pass:
User Impact
Crash-orphaned session temp files are reclaimed on the next Gateway or embedded-TUI startup without risking the only recoverable copy and without adding work to session reads.
Evidence
pnpm buildpassed.pnpm check:changedpassed for all six touched files, including core and core-test typechecks.tbx_01kww1cytcgctj7rzjm3g6rczw.SIGKILLafter temp staging, backdated the orphan, and verified the startup migration removed it.