investigate(memory-core): root-cause for #84882 dreaming silent daily-file deletion#94625
investigate(memory-core): root-cause for #84882 dreaming silent daily-file deletion#94625googlerest wants to merge 3 commits into
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed July 1, 2026, 2:40 PM ET / 18:40 UTC. Summary PR surface: Source +95, Tests +68. Total +163 across 3 files. Reproducibility: yes. for the PR defect by source inspection: the after-snapshot is inside the success path and skipped when an earlier awaited Dreaming step throws. No high-confidence current-main reproduction exists yet for the linked mass-deletion root cause. 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:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Move the comparison into a failure-safe per-workspace boundary while keeping it read-only, then require redacted real Dreaming proof before merge. Do we have a high-confidence way to reproduce the issue? Yes for the PR defect by source inspection: the after-snapshot is inside the success path and skipped when an earlier awaited Dreaming step throws. No high-confidence current-main reproduction exists yet for the linked mass-deletion root cause. Is this the best way to solve the issue? No. The diagnostic is a plausible investigation aid, but the best version must compare snapshots even when a workspace run fails and then prove that behavior in a real Dreaming run. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 477b27b6f87e. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +95, Tests +68. Total +163 across 3 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)
|
…g run to catch openclaw#84882 deletions Issue openclaw#84882 reports daily memory files silently disappearing during the nightly Dreaming run. Static review of memory-core and @openclaw/fs-safe found no deterministic deletion path (see PR openclaw#94625 notes), so this adds a diagnostic-only integrity check: snapshot top-level memory/*.md files before and after each per-workspace dreaming pass and log loudly if any present-before files are gone after, with size/mtime for forensics. Never throws and never mutates files; a failed snapshot just skips the check for that run.
… file deletion)
…g run to catch openclaw#84882 deletions Issue openclaw#84882 reports daily memory files silently disappearing during the nightly Dreaming run. Static review of memory-core and @openclaw/fs-safe found no deterministic deletion path (see PR openclaw#94625 notes), so this adds a diagnostic-only integrity check: snapshot top-level memory/*.md files before and after each per-workspace dreaming pass and log loudly if any present-before files are gone after, with size/mtime for forensics. Never throws and never mutates files; a failed snapshot just skips the check for that run.
83fd7a2 to
494317b
Compare
|
Behavior addressed: CI failures on push — Real environment tested: macOS arm64 (M4), Darwin 25.5.0, Node v25.9.0, branch Exact steps or command run after this patch: Evidence after fix: Observed result after fix: lint error fixed by removing the unnecessary What was not tested: full GH Actions CI matrix not re-run locally; relying on this push to re-trigger it. Did not exercise the dreaming runtime integration end-to-end (this PR is diagnostic-only snapshot code; no live dreaming run was executed). |
|
This pull request has been automatically marked as stale due to inactivity. |
Related: #84882
What Problem This Solves
memory-coreDreaming silently deletes daily memory files (memory/YYYY-MM-DD.md) — 46+ files vanished in one incident, then a second incident (May 30) wiped 171 -> 7 files. #94537 already landed atomic-write hardening for the single current-day write path, but that PR explicitly does not identify the deletion mechanism, and its fix shape (single-file crash-truncation) doesn't match the reported symptom (many distinct historical dates vanishing in one run).This PR is a root-cause hunt that did not find the mechanism yet, plus diagnostic instrumentation to catch it red-handed on the next reproduction.
Why This Change Was Made
What I checked and ruled out:
repairShortTermPromotionArtifacts(the exact log line implicated: "normalized recall artifacts before dreaming") only mutates the recall store (JSON/SQLite via plugin state), never touchesmemory/*.md.scrubDreamingNarrativeArtifactsonly renames*.jsonlsession transcripts, gated by filename suffix — cannot touch.mdfiles.applyShortTermPromotionsonly writesMEMORY.md(long-term), never deletes daily files.writeDailyDreamingPhaseBlock(the function fix(memory-core): harden dreaming daily-file writes and drain dangling recall refs #94537 hardened) only ever touches today's single file per call — cannot explain ~46 distinct historical dates disappearing in one run.memory/2026-05-29-1740.md-style files from the issue thread tosrc/hooks/bundled/session-memory/handler.ts(the/new//resetsession-memory hook) — confirmed intentional behavior, not data loss, but it does pollutememory/with non-YYYY-MM-DD.md-shaped files.@openclaw/fs-safewrite path used by that hook (root.write-> pinned write helper -> Pythonos.unlink(basename, dir_fd=...)) end to end per this repo's dependency-contract-proof rule. Every mutation is single-basename-scoped via dir_fd; no directory-wide glob/cleanup logic anywhere in the chain.None of the above can produce the reported symptom. Root cause remains unknown.
What this PR adds (diagnostic only):
extensions/memory-core/src/dreaming-integrity-guard.tssnapshots top-levelmemory/*.mdfilenames + size + mtime before and after each per-workspace dreaming pass (dreaming.ts). If any file present in the "before" snapshot is absent in the "after" snapshot, it logslogger.errorwith the full list (name, size, mtime), so the next occurrence leaves a log trail pointing at which dreaming run it happened in, rather than relying on the reporter's own external backup/cron diffing.fs.readdir/fs.stat.User Impact
No user-visible behavior change. This is read-only diagnostic instrumentation; dreaming runs produce identical output. The only observable difference is an additional
logger.errorentry in the rare case where a top-levelmemory/*.mdfile disappears between dreaming snapshots — which is exactly the bug this is trying to catch.Evidence
New tests cover: missing
memory/dir (ok, empty snapshot), filtering to top-level.mdonly, detecting a removed file between snapshots, no false positives when nothing changed, and no false positives when either snapshot failed.Real environment tested: macOS arm64 (M4), Darwin 25.5.0, Node v25.9.0, branch
investigate/84882-dreaming-file-deletion, commit494317b886(rebased ontoupstream/main).Status
Still draft / WIP. This does not fix #84882 — it's instrumentation to catch the actual mechanism red-handed on the next reproduction. Will convert from draft once either (a) the integrity log fires and points at a real culprit, or (b) enough reproductions accumulate to rule this approach out.