Repository navigation
fix(orchestration): refuse Task re-open under a live worker; allow stop re-issue on a stranded row - #19551
Conversation
…op re-issue on a stranded row
|
This run was cancelled 🛑 The workflow was cancelled before completion. Please check the link below for details. |
📝 WalkthroughWalkthrough
Merge Risk: 🟡 Moderate · up to Cross-runtime recovery can prevent stranded worker stops, but a late result from the prior runtime may overwrite the replacement stop's outcome and leave worker lifecycle state incorrect. Fence stop settlement and unknown outcomes by runtime epoch before merging. 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Full details: Description checkExplanation The description explains the changes, rationale, exclusions, and verification results, but it omits several required template sections, including ELI5, Linked Issue in the required format, Visual Proof or N/A, Testing checklist, AI Disclosure, Review, Agent skill upstream boundary, Notes, and the main Checklist. Resolution Add all missing template sections. Provide the required issue link using
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Advanced
Run ID: 4db8c16b-e62b-4d3b-8cd9-de8f7b72b953
📒 Files selected for processing (4)
src/main/runtime/orchestration/db-stopping-worker-task-guard.test.tssrc/main/runtime/orchestration/db/tasks/task-status-transition.tssrc/main/runtime/orchestration/db/worker-dispatch/worker-dispatch-stop.tssrc/main/runtime/rpc/methods/orchestration/worker/worker-stop.ts
Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review.
…e main static analysis The 7 auto.components.settings.TerminalPane.minimumContrast.* entries added by #18126 have zero call sites; the shipped component reads settings.contrast.*. Because the runtime-required catalog classifies any key with no literal-default call site as required, the orphans broke 'Verify runtime-required localization catalog' on main and red-lit every PR in the repo. Deleting them is the root-cause fix: regenerating would instead add dead strings to the boot bundle. On main+delete, --fix regenerates a byte-identical catalog and the CI step exits 0. Merged with 'test / tests node 24 3/8' red: that failure is an unrelated main break from the #19542/#19551 collision, not from this change.

Split out of #19347 (the SSH exit-certification half is being redesigned separately).
What
updateTaskStatusalready refusescompleted/failedwhile a live supervised worker holds the Task. It now runs the same check when a Task is moved back todispatchedfrom any other status. A no-op re-assert ofdispatchedstays legal.worker-stopre-issue on a stranded row.beginWorkerStopaccepts astoppingrow only when itsruntime_epochis not this runtime's, meaning the runtime that started the stop died mid-flight. Same-epoch stays refused so an in-flight stop's exit event is still read as that stop succeeding, not as a crash. Same predicate asfailActiveDispatchOnExit.Why
A
task-update --status dispatchedunder astoppingworker left the Task pointing at a worker whose own lifecycle could no longer settle its report; the throw then rolled back the coordinator's wholecheckbatch. No workflow issues that command, so this is defensive.The stop re-issue: a runtime dying between marking
stoppingand closing the terminal leaves the row stranded. Main already has one escape (worker-showmarks a foreign-epochstoppingrowstop_unknown, thenworker-abandonworks); this adds the direct one, where re-runningworker-stopactually attempts the close and lands on an honeststoppedorstop_unknown.Not included
The no-throw settlement path,
isLegalLifecycleTransition,worker_not_settleable, and the state-space enumeration test from #19347. With the guard in place the bad triple is unreachable, and no shipped database realistically holds it.Review note
CodeRabbit asked to fence
settleWorkerStop/markWorkerStopUnknownby epoch against a re-issue racing the old runtime's pending settle. The runtime id is a per-process UUID; a new epoch exists only after the old process is gone, so its pending settle cannot run. No change.Verification
db-stopping-worker-task-guard.test.ts: 7 cases. A/B on unpatched main: 3 fail (both guard cases, the re-issue), 4 controls pass. 7 of 7 with the fix.tc:node, changed-code quality (0 findings), max-lines ratchet,git diff --check.Source: 3 files, +29 / -10.