refactor: add task session registry maintenance seam#93734
Conversation
|
Codex review: needs maintainer review before merge. Reviewed June 18, 2026, 5:29 PM ET / 21:29 UTC. Summary PR surface: Source +38, Tests +128, Other +3. Total +169 across 6 files. Reproducibility: not applicable. as a bug reproduction: this is a behavior-neutral refactor seam. The changed behavior is still exercisable with disposable state through 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. Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Merge the narrow per-store seam only after maintainer review accepts the bounded session-state risk on the final head, leaving the SQLite flip, migrations, and broader session ownership under the canonical tracker. Do we have a high-confidence way to reproduce the issue? Not applicable as a bug reproduction: this is a behavior-neutral refactor seam. The changed behavior is still exercisable with disposable state through Is this the best way to solve the issue? Yes. For this Path 3 slice, extracting the store-sized prune under AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 39e9336d4031. Label changesLabel justifications:
Evidence reviewedPR surface: Source +38, Tests +128, Other +3. Total +169 across 6 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
|
60157b3 to
98e7ba1
Compare
98e7ba1 to
1153f94
Compare
Summary
openclaw tasks maintenanceresponsible for task and flow registry maintenance while delegating each session store prune to the new per-store boundary.skipMaintenanceon apply.runSessionRegistryMaintenanceForStoreis the right transaction-sized boundary for the SQLite follow-up.Linked context
Which issue does this close?
Part of #88838
Which issues, PRs, or discussions are related?
Related Pebbles
clawdbot-d02.1.9.1.39Was this requested by a maintainer or owner?
Maintainer-delegated OpenClaw Path 3 task.
Real behavior proof (required for external PRs)
openclaw tasks maintenance --applyno longer owns direct mutable session-store pruning; the prune runs through a named per-store session-registry maintenance helper.upstream/mainfdb042b9ce09cdd8a2eff786f779e0f3004d955awith head1153f94ef45d0a51daac074b91488f98cef5c875.OPENCLAW_STATE_DIR/OPENCLAW_CONFIG_PATHwith four session rows and two cron jobs throughsaveCronStore; ranpnpm --silent openclaw tasks maintenance --apply --json; inspectedagents/main/sessions/sessions.jsonafterward. Also ran focused Vitest, boundary guard, oxfmt, oxlint, both tsgo wrappers,git diff --check, and.agents/skills/autoreview/scripts/autoreview --mode branch --base upstream/main.runningCronJobs: 1,pruned: 1, storebeforeCount: 4,afterCount: 3, andpreservedRunning: 1. Focused Vitest passed 3 shards; boundary guard passed; oxfmt check passed; oxlint passed; both tsgo wrappers exited 0; autoreview reported no accepted/actionable findings./tmp; SQLite runtime flip, migrations, and doctor repair remain follow-up work under Track core session/transcript SQLite migration via accessor seam #88838.src/commands/tasks.tspreviously importedloadSessionStore,pruneStaleEntries, andupdateSessionStoredirectly for this maintenance path.Tests and validation
node scripts/run-vitest.mjs src/config/sessions/session-registry-maintenance.test.ts src/commands/tasks.test.ts test/scripts/check-session-accessor-boundary.test.tsnode scripts/check-session-accessor-boundary.mjspnpm exec oxfmt --check src/config/sessions/session-registry-maintenance.ts src/config/sessions/session-registry-maintenance.test.ts src/config/sessions.ts src/commands/tasks.ts scripts/check-session-accessor-boundary.mjs test/scripts/check-session-accessor-boundary.test.tsnode scripts/run-oxlint.mjs src/config/sessions/session-registry-maintenance.ts src/config/sessions/session-registry-maintenance.test.ts src/config/sessions.ts src/commands/tasks.ts scripts/check-session-accessor-boundary.mjs test/scripts/check-session-accessor-boundary.test.tsnode scripts/run-tsgo.mjs -p tsconfig.core.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core.tsbuildinfonode scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test.tsbuildinfogit diff --check upstream/main..HEADpnpm --silent openclaw tasks maintenance --apply --jsonwith isolatedOPENCLAW_STATE_DIRandOPENCLAW_CONFIG_PATH..agents/skills/autoreview/scripts/autoreview --mode branch --base upstream/mainRegression coverage added in
src/config/sessions/session-registry-maintenance.test.ts; boundary ratchet updated inscripts/check-session-accessor-boundary.mjsandtest/scripts/check-session-accessor-boundary.test.ts.Risk checklist
Did user-visible behavior change? (
Yes/No)No.
Did config, environment, or migration behavior change? (
Yes/No)No.
Did security, auth, secrets, network, or tool execution behavior change? (
Yes/No)No.
What is the highest-risk area?
Preserving the exact task-maintenance pruning semantics while moving the store write behind a helper.
How is that risk mitigated?
Existing command tests still cover task maintenance JSON behavior, and new helper tests cover dry-run/apply, running cron preservation, missing stores, and skip-maintenance preservation of non-cron rows.
Current review state
What is the next action?
Draft PR ready for maintainer review and CI.
What is still waiting on author, maintainer, CI, or external proof?
CI and maintainer decision after the rebased branch push. Local focused proof, real disposable command proof, and autoreview are complete.
Which bot or reviewer comments were addressed?
ClawSweeper posted an infrastructure/schema failure rather than actionable code feedback. Local autoreview completed cleanly after rebase.