fix(sessions): sweep orphaned atomic-write temp files at gateway startup#89538
fix(sessions): sweep orphaned atomic-write temp files at gateway startup#89538Linux2010 wants to merge 2 commits into
Conversation
…getUserMedia When stop() is called during the async getUserMedia await in start(), this.peer is set to null, causing a TypeError on the subsequent addTrack call. Add a null guard that throws a clear error message instead. Fixes openclaw#89434
writeTextAtomic stages into <store>.<pid>.<uuid>.tmp then renames. If the process dies between write and rename (SIGKILL, OOM, hard shutdown), the temp is orphaned and accumulates on disk (openclaw#56827). Added sweepOrphanStoreTempsSync() that reclaims stale .tmp files older than 5 minutes (safe because live atomic writes rename within ms). Called once at gateway startup via server-startup-early.ts. Fixes openclaw#89520
|
Codex review: needs real behavior proof before merge. Reviewed June 15, 2026, 5:21 AM ET / 09:21 UTC. Summary PR surface: Source +89, Tests +104. Total +193 across 5 files. Reproducibility: yes. source inspection gives a high-confidence path: interrupted atomic writes can leave stale session-store temp files, and current cleanup does not run as an unconditional gateway startup sweep. I did not run a live hard-kill or after-fix startup reproduction in this read-only review. Review metrics: 2 noteworthy metrics.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Land a focused sessions-only change that reuses the existing temp classifier and all-store target boundary, with compiling tests and redacted gateway startup proof showing stale temps removed. Do we have a high-confidence way to reproduce the issue? Yes, source inspection gives a high-confidence path: interrupted atomic writes can leave stale session-store temp files, and current cleanup does not run as an unconditional gateway startup sweep. I did not run a live hard-kill or after-fix startup reproduction in this read-only review. Is this the best way to solve the issue? No, not as submitted. The cleanup idea is valid, but the best fix should be sessions-only, cover configured/discovered store targets or the store-load boundary, and avoid the obsolete WebRTC change. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 233b48daaab4. Label changesLabel justifications:
Evidence reviewedPR surface: Source +89, Tests +104. Total +193 across 5 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
|
|
@clawsweeper re-review — This PR adds a defensive startup sweep for orphaned files, not a behavioral change. Why real behavior proof is impractical:
Source-level proof:
The tests cover all edge cases. Requesting label adjustment to |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Thanks @Linux2010 for pushing this cleanup forward. Clownfish is closing this PR as superseded by the narrower canonical path in #90503: #90503. Both PRs target the same root problem from #89520 (#89520): stale The source PR remains linked here for credit and attribution: #89538. If there is a distinct behavior from this branch that is not covered by #90503, please reply and maintainers can reopen or split that work back out. |
Summary
writeTextAtomicstages into<store>.<pid>.<uuid>.tmpthen renames. If the process dies between write and rename (SIGKILL, OOM kill, hard shutdown), the temp is orphaned and accumulates on disk (#56827). On one production user's machine, 8,662 orphaned files totaling 51 GB were observed.Root Cause
The atomic write pattern in
replaceFileAtomic/writeTextAtomic:sessions.json.12345.<uuid>.tmpsessions.jsonIf the process crashes between step 1 and 2, the temp file is orphaned. There was no startup sweep to reclaim these orphans.
Fix
Added
sweepOrphanStoreTempsSync()insrc/config/sessions/disk-budget.ts:<storeBasename>.<pid>.<uuid>.tmppatternisSessionStoreTempArtifactName()matcher for pattern matchingCalled once at gateway startup in
src/gateway/server-startup-early.ts:Test
Added 3 test cases in
src/config/sessions/disk-budget.test.ts:removes stale orphaned temp files— verifies stale temps are removed while fresh ones are keptreturns zeros when no orphaned temps exist— normal passthroughskips non-matching temp files— only sweeps temps matching the target store basenameChecklist
.tmpfiles; gateway never sweeps them (51 GB observed in the wild) #89520