fix: wire SNAPSHOT_INTERVAL to a periodic timer that triggers mem::snapshot-create#1010
fix: wire SNAPSHOT_INTERVAL to a periodic timer that triggers mem::snapshot-create#1010yingliang-zhang wants to merge 2 commits into
Conversation
…apshot-create The SNAPSHOT_INTERVAL config value was read and logged at boot but no setInterval timer was ever created, so periodic snapshots never fired. Snapshots only happened when manually triggered via the API/MCP. Add a setInterval that triggers mem::snapshot-create at the configured interval, following the same pattern as auto-forget, lesson-decay, and consolidation timers (try/catch + unref). Fixes rohitg00#1006 Signed-off-by: yingliang-zhang <zhangyingliang@outlook.com>
|
@yingliang-zhang is attempting to deploy a commit to the rohitg00's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughWhen snapshotting is enabled, the worker now derives a millisecond interval from the configured snapshot interval, starts a periodic timer that triggers ChangesSnapshot scheduling
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant Worker as src/index.ts
participant Timer as setInterval
participant SDK as sdk.trigger
participant SnapshotFn as mem::snapshot-create
Worker->>Timer: start interval (snapshotIntervalMs)
loop every tick
Timer->>SDK: trigger(function_id="mem::snapshot-create")
SDK->>SnapshotFn: execute snapshot creation
SDK-->>Timer: errors suppressed via try/catch
end
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/index.ts (1)
359-361: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winBoot log doesn't reflect whether the periodic timer actually started.
This
bootLogalways fires whensnapshotConfig.enabled, even ifsnapshotIntervalMswas0and the guard at Line 351 skipped creating the timer. Operators would see "Git snapshots: ... (every 0s)" implying periodic snapshots are running, when in fact only manual/API-triggered snapshots work — the exact gap this PR is meant to close.📝 Proposed fix to clarify boot log
- bootLog( - `Git snapshots: ${snapshotConfig.dir} (every ${snapshotConfig.interval}s)`, - ); + bootLog( + snapshotIntervalMs > 0 + ? `Git snapshots: ${snapshotConfig.dir} (every ${snapshotConfig.interval}s)` + : `Git snapshots: ${snapshotConfig.dir} (periodic timer disabled, SNAPSHOT_INTERVAL=0 — manual/API trigger only)`, + );🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/index.ts` around lines 359 - 361, The boot log in the snapshot startup path is misleading because it always reports periodic Git snapshots even when the timer was not created. Update the logic around the snapshot initialization in src/index.ts so the `bootLog` tied to the snapshot setup only runs when `snapshotIntervalMs` is actually greater than zero and the interval timer is started, and use the existing snapshot-related symbols like `snapshotConfig` and `snapshotIntervalMs` to keep the message aligned with real behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/index.ts`:
- Around line 359-361: The boot log in the snapshot startup path is misleading
because it always reports periodic Git snapshots even when the timer was not
created. Update the logic around the snapshot initialization in src/index.ts so
the `bootLog` tied to the snapshot setup only runs when `snapshotIntervalMs` is
actually greater than zero and the interval timer is started, and use the
existing snapshot-related symbols like `snapshotConfig` and `snapshotIntervalMs`
to keep the message aligned with real behavior.
…timer Address CodeRabbit nitpick: the boot log always reported 'every Ns' even when the timer guard (snapshotIntervalMs > 0) skipped creating it, making SNAPSHOT_INTERVAL=0 misleadingly look like periodic snapshots were running. Signed-off-by: yingliang-zhang <zhangyingliang@outlook.com>
|
Addressed the CodeRabbit nitpick in commit |
Summary
The config value (default 3600s) was read and logged at boot —
Git snapshots: ... (every 3600s)— but nosetIntervaltimer was ever created. Periodic snapshots never fired automatically. Snapshots only happened when manually triggered via the API/MCP endpoint or thememory_snapshot_createMCP tool.This means that in a long-running daemon, if no one manually triggers a snapshot, data could be lost on crash/restart with only the last manual snapshot available for recovery.
Fix
Add a
setIntervalthat triggersmem::snapshot-createat the configured interval, following the exact same pattern as the existingauto-forget,lesson-decay,consolidation, andrecent-searches-sweeptimers:A guard (
snapshotIntervalMs > 0) prevents an infinite loop if someone explicitly setsSNAPSHOT_INTERVAL=0.How to verify
SNAPSHOT_ENABLED=trueandSNAPSHOT_INTERVAL=10in.envagentmemoryagentmemory mcpand triggermemory_snapshot_listperiodic snapshotcommit appears with a timestamp ~10s after bootdaemon.err.logforSnapshot createdinfo entriesTest results
npm run build— cleannpx vitest run test/snapshot.test.ts— 5/5 passedembedding-provider.test.tsunrelated to this change, confirmed by running tests on unmodifiedmain)Fixes #1006
Summary by CodeRabbit