Add named snapshot database targets#94799
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed June 19, 2026, 1:08 AM ET / 05:08 UTC. Summary PR surface: Source +57, Tests +111. Total +168 across 4 files. Reproducibility: not applicable. as a bug reproduction; this is a feature PR. Source inspection confirms the proposed handler and tests exercise named target resolution, but real packaged CLI execution has not been proven. 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: Land this only after the provider and base CLI PRs are accepted, docs describe the named targets, and redacted real Do we have a high-confidence way to reproduce the issue? Not applicable as a bug reproduction; this is a feature PR. Source inspection confirms the proposed handler and tests exercise named target resolution, but real packaged CLI execution has not been proven. Is this the best way to solve the issue? Unclear as merge-ready. The implementation uses the right state path helpers and is a plausible narrow layer, but the best solution still requires maintainer acceptance of the stack, docs, and real CLI proof. Full review comments:
Overall correctness: patch is correct AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against af3c10626c4b. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +57, Tests +111. Total +168 across 4 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
|
|
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
This is PR 3 in the snapshot stack. It makes the core snapshot command understand OpenClaw's named SQLite databases instead of requiring operators to know internal file paths.
Adds:
openclaw snapshot create --target global --repository <dir>for the shared state databaseopenclaw snapshot create --agent <id> --repository <dir>for a per-agent database--db,--target, and--agentremain mutually exclusiveKeeps:
--db <path>from PR 2 for non-OpenClaw or advanced caller pathsWhy
Ryan's issue (#94675) called out that live SQLite files and their WAL/SHM companions are not safe sync artifacts for hosted deployments. PR #94646 made the database layout more explicit by separating shared state from per-agent state. This PR uses those core path helpers so snapshotting can target the logical OpenClaw database units directly:
state/openclaw.sqliteagents/<agent>/agent/openclaw-agent.sqliteThat keeps the operator-facing contract small: ask OpenClaw for a syncable snapshot artifact, not for a copy of whatever live SQLite files happen to exist on disk.
Stack
Scope
This PR does not add object storage, scheduling, restore-on-boot, leases, or WAL bundle deltas. Those stay in later phases. This only proves the CLI can name OpenClaw's own SQLite targets and resolve them through core-owned path helpers.
Real behavior proof
Behavior or issue addressed:
openclaw snapshot createcan now create snapshots from named OpenClaw database targets (--target global,--agent <id>) without requiring users to locate and pass live SQLite paths manually.Real environment tested:
Windows checkout at
C:\src\openclaw-snapshot-pr1, source test harness with temporary SQLite databases and local snapshot repositories.Exact steps or command run after this patch:
node scripts/run-vitest.mjs run src/commands/snapshot.test.ts src/cli/program/register.snapshot.test.ts src/snapshot/snapshot-provider.test.tsnode_modules\.bin\oxlint src\commands\snapshot.ts src\commands\snapshot.test.ts src\cli\program\register.snapshot.ts src\cli\program\register.snapshot.test.tsgit diff --checkEvidence after fix:
Vitest passed 3 shards:
src/commands/snapshot.test.ts(6 tests),src/cli/program/register.snapshot.test.ts(7 tests), andsrc/snapshot/snapshot-provider.test.ts(5 tests).oxlintandgit diff --checkcompleted with no output.Observed result after fix:
The command resolves
--target globalto the shared OpenClaw state database, resolves--agent "Ops Team"to the normalized per-agent database path, records default manifest ids/kinds for both, preserves explicit--db, and rejects ambiguous selector combinations.What was not tested:
No live gateway runtime, object storage upload, scheduled backup loop, restore-on-boot path, lease/failover path, or WAL bundle/delta behavior was tested in this PR.