refactor: route boot session mapping through accessor#96225
Conversation
|
Codex review: needs maintainer review before merge. Reviewed June 24, 2026, 9:47 AM ET / 13:47 UTC. Summary PR surface: Source +57, Tests +2, Other +2. Total +61 across 4 files. Reproducibility: not applicable. This PR is an internal refactor preserving existing boot behavior rather than a bug report. The relevant restore/delete behavior is covered by existing boot tests and the PR body's live gateway proof. Review metrics: none identified. 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:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Proceed with maintainer review and normal merge gates for this accessor-boundary slice, leaving SQLite adapter/importer behavior on the canonical tracker. Do we have a high-confidence way to reproduce the issue? Not applicable: this PR is an internal refactor preserving existing boot behavior rather than a bug report. The relevant restore/delete behavior is covered by existing boot tests and the PR body's live gateway proof. Is this the best way to solve the issue? Yes: for the stated Path 3 goal, moving the one-key temporary boot mapping lifecycle into the session accessor is the right owner boundary, while boot still owns boot prompt construction and command execution. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against f1e38f2ed637. Label changesLabel justifications:
Evidence reviewedPR surface: Source +57, Tests +2, Other +2. Total +61 across 4 files. View PR surface stats
Acceptance criteria:
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
|
fae77dc to
8fe3fb8
Compare
8fe3fb8 to
c8dd6d1
Compare
What Problem This Solves
src/gateway/boot.tsstill needed direct session-store snapshot/restore access for the temporaryagent:main:bootmapping. That kept boot startup outside the Path 3 accessor boundary tracked by #88838.Why This Change Was Made
This moves boot temporary session mapping preservation into a narrow named session accessor operation. The boot runner keeps the existing behavior: snapshot any prior boot mapping, run the isolated boot session, then restore the prior mapping or delete the temporary boot mapping if none existed.
User Impact
No intended user-visible behavior change. Boot startup continues to use an isolated boot session while leaving any prior boot session mapping unchanged after the boot run completes.
Evidence
node scripts/run-vitest.mjs src/gateway/boot.test.ts- passed, 64 testsnode scripts/run-vitest.mjs test/scripts/check-session-accessor-boundary.test.ts- passed, 28 testsnode scripts/check-session-accessor-boundary.mjs && git diff --check upstream/main..HEAD- passednode scripts/run-tsgo.mjs -p tsconfig.core.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core.tsbuildinfo- passednode scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test.tsbuildinfo- passed.agents/skills/autoreview/scripts/autoreview --mode branch --base upstream/main- clean, no accepted/actionable findingsReal behavior proof
Behavior addressed: Boot startup preserves/restores the temporary
agent:main:bootsession mapping through the new session accessor boundary: existing mappings are restored, and temporary mappings are deleted when no prior mapping existed.Real environment tested: Local live gateway in
/Users/phaedrus/Projects/clawdbot, branch build at3cdb7fce74a88f08230028660c54c9ea15ac753fbefore the final conflict-free rebase, OpenClaw 2026.6.9, managed gateway on port 18789. Final pushed headc8dd6d107d7c9e3c37c4e855bc125ec3711e0c04was then verified with focused tests, boundary guard, type probes, and autoreview againstupstream/main17066f2d7c019d92fc090762484359f751976f50.Exact steps or command run after this patch:
Evidence after fix: Proof nonce
path3-boot-mqrb7a2e. With a synthetic pre-existingagent:main:bootrow, the live boot run restoredsessionId=path3-boot-mqrb7a2e-existingandupdatedAt=1700000000000after creating isolated boot transcriptsboot-2026-06-24_00-02-53-057-ece6091d.jsonlandboot-2026-06-24_00-02-53-057-ece6091d.trajectory.jsonl. With no prior boot row, the live boot run created isolated boot transcriptsboot-2026-06-24_00-03-25-036-73b9c902.jsonlandboot-2026-06-24_00-03-25-036-73b9c902.trajectory.jsonl, then left noagent:main:bootmapping. Transcript headers showedcwd=/Users/phaedrus/clawdandtype=session/session.started. Cleanup removed four proof transcripts, removed the temporaryBOOT.md, and leftfinalBootMappingPresent=falseandfinalBootFileExists=false. The live service was restored to cleanmainat6f2869c296ffc3e82ad22e0d744bdb9c73eb3177; final/healthzreturned{"ok":true,"status":"live"}and final/readyzreturnedready:true, no failing checks, andeventLoop.degraded:false.Observed result after fix: The live gateway created and used isolated boot sessions while preserving a prior boot mapping when present and deleting the temporary boot mapping when absent. The proof left no synthetic boot mapping, temporary boot file, or proof transcripts behind, and the live service was restored to the saved healthy checkout.
What was not tested: The future SQLite-backed adapter/transaction implementation, doctor migration behavior, plugin SDK compatibility, fallback/dual-read behavior, and a second live service restart on the final post-rebase SHA. The final SHA was covered by focused Vitest, boundary guard, type probes, and autoreview after rebasing onto current
upstream/main.