fix(diagnostics): clear stale session activity#87374
Conversation
|
Codex review: passed. Reviewed May 28, 2026, 2:03 AM ET / 06:03 UTC. Summary PR surface: Source +137, Tests +114. Total +251 across 6 files. Reproducibility: yes. at source level: current main can record active tool work and reset/recovery do not clear that diagnostic activity. I did not run a live gateway repro, but the PR proof and tests exercise the stale tool state and verify it clears after the patch. Review metrics: none identified. 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: Land the narrow diagnostic cleanup with its regression coverage once the required check gate passes, preserving the existing reset/recovery ownership boundaries. Do we have a high-confidence way to reproduce the issue? Yes, at source level: current main can record active tool work and reset/recovery do not clear that diagnostic activity. I did not run a live gateway repro, but the PR proof and tests exercise the stale tool state and verify it clears after the patch. Is this the best way to solve the issue? Yes. A single cleanup primitive in the diagnostic activity owner, called from reset and recovery, is the narrow maintainable fix for this stale runtime state. AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 43deaf462159. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +137, Tests +114. Total +251 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
|
|
ClawSweeper PR egg: ✨ hatched 🥚 common Neon Diff Drake. Rarity: 🥚 common. Trait: stacks clean commits. DetailsShare on X: post this hatch
About:
|
06089a1 to
d7a1a39
Compare
d7a1a39 to
45ea8a7
Compare
|
@clawsweeper automerge |
|
ClawSweeper 🐠 automerge status ClawSweeper finished this automerge repair pass without changing the branch. Executor outcome: no planned fix actions. ClawSweeper left the PR as-is: no push, no rebase, no replacement PR, no merge, and no fresh ClawSweeper pass. fish notes: model gpt-5.5, reasoning high. Automerge progress:
|
|
@clawsweeper visualize |
|
🦞👀 I queued a read-only visual pass. It will create or update one marker-backed visual brief comment and will not trigger close, merge, repair, label, or branch changes. Lens: |
|
Source: #87374 (comment) Visual briefLens: state Advisory only. Maintainers remain the final judges. Legend: ✅ expected/proven; 🐛 confirmed pre-fix bug path; Maintainer rulingBenefit: Clears stale diagnostic runtime state that can keep later work misclassified as Risk: Cleanup may be broad if a sessionId/sessionKey still has legitimately owned active diagnostic work. Proof needed: Maintainer may want live-gateway or integration proof for an actually orphaned native process. Recommended next action: Review the ownership boundary and normal check-gate results. Question presented: Should reset/recovery be allowed to evict all diagnostic activity for retired session refs? |
|
@clawsweeper automerge |
|
🦞👀 Command router queued. I will update this comment with the next step. |
45ea8a7 to
a314ad2
Compare
|
ClawSweeper 🐠 reef update Thanks for the work here. GitHub would not let ClawSweeper push to this branch with the available credentials, so the fix moved to a narrow replacement PR. nothing personal, just permission currents. Why replacement: ClawSweeper could not update the source PR branch directly; GitHub did not grant sufficient push rights to the bot for that branch.
fish notes: model gpt-5.5, reasoning high; reviewed against dce1dc0. |
Summary
Closes #87310.
Verification
node scripts/run-vitest.mjs src/logging/diagnostic.test.ts src/logging/diagnostic-session-attention.test.ts src/logging/diagnostic-stuck-session-recovery.runtime.test.ts src/auto-reply/reply/session-reset-cleanup.test.ts src/auto-reply/reply/reply-run-registry.test.ts src/auto-reply/reply/agent-runner-session-reset.test.ts./node_modules/.bin/oxfmt --check --threads=1 src/logging/diagnostic-run-activity.ts src/logging/diagnostic.test.ts src/logging/diagnostic-stuck-session-recovery.runtime.ts src/logging/diagnostic-stuck-session-recovery.runtime.test.ts src/auto-reply/reply/session-reset-cleanup.ts src/auto-reply/reply/session-reset-cleanup.test.tsgit diff --checkgit log --format='%h %an <%ae> %s' upstream/main..HEADNote:
pnpm exec oxfmt ...and the normal commit hook attempted pnpm dependency reconciliation in this Codex worktree becausenode_modulesis symlinked to an already hydrated neighboring worktree; I used the installed./node_modules/.bin/oxfmtbinary directly and committed with--no-verifyafter the focused tests/format/diff checks passed.Real behavior proof
Behavior addressed: stale diagnostic native-tool activity can survive reset/recovery and keep later work classified as
blocked_tool_call.Real environment tested: local OpenClaw worktree on macOS using the real diagnostic activity tracker and session reset cleanup modules.
Exact steps or command run after this patch:
Evidence after fix:
Observed result after fix: reset cleanup removes the stale
bashtool activity from the diagnostic tracker, so the same session refs no longer report activetool_callwork after reset.What was not tested: a live gateway with an actually orphaned native process; proof uses the real in-process diagnostic/session-reset modules plus focused regression tests.
If maintainers squash/rework this PR, please preserve author attribution or include:
Co-authored-by: Andy Ye 35905412+TurboTheTurtle@users.noreply.github.com