Add core snapshot provider proof#94694
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed June 19, 2026, 12:00 AM ET / 04:00 UTC. Summary PR surface: Source +388, Tests +242. Total +630 across 7 files. Reproducibility: no. live repro was run in this read-only review. Source inspection shows the verifier omits sqlite-vec loading while current memory code creates vec0 virtual tables that require the sqlite-vec extension path. 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: Fix sqlite-vec-aware verification, add real after-patch proof, and land only if maintainers approve the core snapshot manifest/provider contract; otherwise narrow the PR to the shared backup helper extraction. Do we have a high-confidence way to reproduce the issue? No live repro was run in this read-only review. Source inspection shows the verifier omits sqlite-vec loading while current memory code creates vec0 virtual tables that require the sqlite-vec extension path. Is this the best way to solve the issue? No, not merge-ready as written. The provider shape is plausible, but the verifier should handle sqlite-vec-backed artifacts and maintainers still need to accept the core durability contract. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 845ad1cf71b9. Label changesLabel justifications:
Evidence reviewedPR surface: Source +388, Tests +242. Total +630 across 7 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
|
3362721 to
9c45304
Compare
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
592e0c5 to
3d1a406
Compare
|
@clawsweeper re-review Rebased on current |
|
🦞🧹 I asked ClawSweeper to review this item again. |
|
Closing this stack slice in favor of the consolidated core snapshot PR: #94805. We collapsed the previous PR1-4 chain into one reviewable feature PR so reviewers can evaluate the provider, CLI, named targets, and safe-sync artifact proof together. The stress harness remains a separate follow-up in #94967. |
Summary
src/snapshot, not an extension/plugin.SqliteSnapshotProviderbacked by a manifest + compactdatabase.sqliteartifact repository.VACUUM INTOprimitive with the existing backup path throughpackages/memory-host-sdk, including sqlite-vec loading and compact-snapshot behavior.*.sqlite-wal,*.sqlite-shm, or*.sqlite-journalsidecars.Why this matters
Scout/Lobster-style hosts persist OpenClaw by syncing files when they are saved. A live SQLite directory is the wrong durability boundary: the main
*.sqlitefile can be incomplete without WAL state, and unmanaged file deltas over live SQLite can observe DB pages, WAL frames, and sidecars at different moments.This PR proves the safer core boundary: SQLite materializes a clean artifact first, the provider verifies it, and the host can sync the completed artifact set instead of the live DB working set. WAL bundles remain a metrics-gated Phase 2 after verified snapshot artifacts and cursors exist.
Scope
This is PR 1 from the snapshot RFC roadmap: core provider proof only. It intentionally does not add
openclaw snapshot ...commands, backup command integration, remote storage, leases, scheduling, WAL bundles, or failover orchestration.RFC context: openclaw/rfcs#20
Database-first state layout: #94646
Related storage discussion: #90370
Verification
node scripts/run-vitest.mjs run src/snapshot/snapshot-provider.test.ts- passed, 1 file / 6 testsnode scripts/run-vitest.mjs run packages/memory-host-sdk/src/host/sqlite-vec.test.ts- passed, 1 file / 9 testsnode_modules\.bin\oxlint src\snapshot packages\memory-host-sdk\src\host\sqlite-snapshot.ts packages\memory-host-sdk\src\engine-storage.ts src\infra\backup-create.ts- passedgit diff --check- passedReal behavior proof
Behavior or issue addressed:
Core SQLite snapshot provider can create, verify, list, and internally restore compact snapshot artifacts from SQLite databases, including WAL-mode state. This proves the safe sync artifact boundary for the database-first SQLite target model landed in #94646.
Real environment tested:
Windows source checkout at
C:\src\openclaw-snapshot-pr1, Node/Vitest source harness againstnode:sqlite.Exact steps or command run after this patch:
node scripts/run-vitest.mjs run src/snapshot/snapshot-provider.test.tsnode scripts/run-vitest.mjs run packages/memory-host-sdk/src/host/sqlite-vec.test.tsnode_modules\.bin\oxlint src\snapshot packages\memory-host-sdk\src\host\sqlite-snapshot.ts packages\memory-host-sdk\src\engine-storage.ts src\infra\backup-create.tsgit diff --checkEvidence after fix:
git diff --checkcompleted with no whitespace errors.Observed result after fix:
The source harness creates a WAL-mode source database, snapshots via the core local provider, verifies the manifest and artifact, restores to a fresh path, and reads both pre-WAL and committed-in-WAL rows from the restored database. It also covers failed create cleanup, artifact tamper detection, signed
user_version, same-millisecond snapshot IDs, and stale restore-target WAL sidecar removal.What was not tested:
Public
openclaw snapshotCLI, backup command integration, object storage providers, scheduled snapshots, WAL bundles, leases, and fresh OpenClaw state-dir boot proof; those are intentionally later PRs.