Repository navigation
fix(workflow): refuse a task-less reset before it clears the lane (#1531) - #1597
Conversation
) (replay of #1532) Replay of #1532 onto main fa932f8. The original head (d29e25f) is on HugoXK/FlyBot with maintainer_can_modify=false, so the change is rebuilt here from main's tree; the original is closed as superseded. `workflow/reset` without a `runId` cleared `lane.active`/`lane.queue` and only then refused a workflow with no task to keep, so a waiting lane lost its queue and a live run with no task lost its Bot ids on a path that never writes or releases them. The refusal now runs before the clears — and before main's new `clearRunTimers` sweep over the lane — so a refused reset writes nothing, releases nothing and leaves the lane as it found it. Fixes #1531 Docs-not-needed: only the order of a refusal path changes; no invariant docs/subsystems/workflow.md states moves. Written-by: Chief
|
Verdict: PASS at 5de8fcf Ran at this tip: Checked at the tip: the extracted tree matches this PR's three blobs ( Not run: full |
Written-by: Chief
Fixes #1531
Owner: Dev4
Reviewer: Reviewer
Replay of #1532: the original head is on a fork we cannot push to (maintainer_can_modify=false), so this PR carries the same change replayed onto current main; the original is closed as superseded.
What changed
workflow/resetwithout arunIdemptiedlane.activeandlane.queueand only then refused a workflow with no task to keep, soThis workflow has no taskcame back after the lane was already cleared. That path neither writes nor releases, so the cleared lane stays in memory and the next ordinary write flushes it to disk. A waiting lane (active: [],last: null) loses every queued task; a live run whosetaskis null loses its ephemeral Bot ids without a release.Replay merge
The original was cut from
c9559ed5. Main is nowfa932f86and also rewroteplugins/workflow/src/service.js(+397/−55), which addedclearRunTimersover the lane's active runs just before the two clears. The refusal now sits in front of that sweep as well, so a refused reset touches neither the lane nor its timers; the rest of main'stake()and therunIdbranch are untouched. The test file and the changelog fragment apply whole.Verification
At this tip, in
plugins/workflow:TZ=UTC node --import ./test/resolve.mjs --test "test/*.test.js"— 180/180 pass. With onlysrc/service.jsreverted to main's version,a refused reset leaves the queue untouchedfails (queueDepth0 !== 1) anda refused reset keeps a run that has no taskfails (activeCount0 !== 1), whilea reset with a task still clears the lane and releases its Botsstays green.Not run:
npm run verifyend to end (nothing outsideplugins/workflow/andchangelog.d/changes, socore/client.jsandpatches/ds-bot/are main's blobs), GitHub CI and the merge queue, and the smoke test (nocore/or host change).Docs-not-needed: only the order of a refusal path changes; no invariant docs/subsystems/workflow.md states moves.
Checkpoint
{ "pr": 1597, "claim": "Dev4", "issue": 1531, "summary": "`workflow/reset` without a `runId` cleared the lane and only then refused a workflow with no task to keep, so a waiting lane lost its whole queue and a live run with no task lost its Bot ids without a release. The refusal now runs before the clears, and before main's `clearRunTimers` sweep, so a refused reset writes nothing, releases nothing and leaves the lane as it found it. The success path and the `runId` branch are unchanged.", "files": [ "plugins/workflow/src/service.js", "plugins/workflow/test/reset.test.js", "changelog.d/1531.fixed.md" ], "checks": { "ran": "TZ=UTC node --import ./test/resolve.mjs --test \"test/*.test.js\" (plugins/workflow)", "result": "green", "at": "5de8fcfad6536f48791950d084f0aa3269ddac3c" }, "next": "none — ready for review" }