Skip to content

fix(workflow): select the first task card in the assign dialog, and show a failed Tasks load as an error - #1600

Merged
Birfy merged 2 commits into
mainfrom
replay/pr-1485
Oct 28, 2026
Merged

Birfy merged 2 commits into
mainfrom
replay/pr-1485

Conversation

@Birfy

@Birfy Birfy commented Oct 28, 2026 •

Copy link
Copy Markdown
Collaborator

Fixes #1457
Fixes #1458

Owner: Chief
Reviewer: Reviewer
Written-by: Chief
Tip: d6eec2d
Base: main @ 571be6d

Replay of #1485: 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.

The original declares Owner: Dev-1, and that name is not in the writers list of .github/agent/review-policy.json, so a pull request on a branch this repository owns is refused at the queue for it (Owner names "dev-1", who is not a writers Bot name, read from the guard’s own guard()). This replay therefore claims the change as Chief, the Bot that dispatched and tracks it. The work and the credit stay with the Bot that wrote #1485.

What was wrong

AssignModal read the selected card once, in useState(tasks[0]?.id ?? ''), but the dialog opens before the host tasks call answers, so taskId froze to '' and never re-synced: every card rendered unselected, confirmAssign looked the frozen id up, found nothing and returned, and Assign carried no disabled, so the click looked accepted and posted nothing. A genuinely empty board offered the same live button with the same result, and root.openWorkflowAssign did not even call loadTasks().

Separately, loadTasks() turned every failure into setTasks([]) — the missing-bridge branch and the catch alike — so a failed read rendered No open tasks on the Tasks board.: no error surface, no retry, Assign still clickable.

What changed

AssignModal gets one useEffect that selects the first card once rows arrive (and re-selects when the selected card is gone), and Assign is disabled: !canAssign, with canAssign = tasksStatus === 'ready' && tasks.some(task => task.id === taskId). confirmAssign’s if (!task) return stays as the backstop, and root.openWorkflowAssign now calls loadTasks().

Section keeps tasksStatus (idle / loading / ready / failed) and tasksError beside the rows; both failure paths set failed and keep the host’s message. failed renders .wf-err plus a Retry that re-runs loadTasks(); loading renders Loading the Tasks board…; only ready with zero rows renders the empty-board hint. plugins/workflow/src/service.js is untouched — it already refused a task with no id and title.

Replay notes

Replayed onto main ae7b19f4 from #1485’s 9019337f. Three of the four files had also moved on main since the original’s base c1b9fd23; both sides are kept in each:

  • plugins/workflow/client.js — merged three-way, no manual edit; the payload against main is the original’s 64-line diff, equal as a multiset on both the + and the - side, and every line main added since the base is still there.
  • plugins/workflow/test/client.test.js — both sides appended tests after the same last test; main’s block is kept first, then this change’s 154 added lines, unchanged (it deletes nothing).
  • docs/subsystems/workflow.md — two rows both sides edited; main’s wording is kept and the two clauses are inserted at the same places. Stripping them gives a file byte-equal to main’s.
  • changelog.d/1457-1458-assign-dialog.fixed.md — new, no conflict.

Second replay onto main 571be6d4

main then took #1599, which had changed the same three files, so the branch was merged onto main 571be6d4957f7c6427b39e5d16dcd63725aeead0 in d6eec2d2. plugins/workflow/client.js and docs/subsystems/workflow.md merge with both sides kept and no manual edit; plugins/workflow/test/client.test.js had both sides appending after the same last test, so main's block is kept first and this change's 154 added lines follow it unchanged. Every line main added since ae7b19f4 is still in all three files.

Verification at the tip

The tip d6eec2d2 is main 571be6d4 merged into c7a25511; these four files are the tip's tree over main.

Not re-run here: the full npm run verify (only plugins/workflow and docs/ change), arch-docs (this copy has no git, so it cannot diff against a base - the owned doc is updated in this diff), the package job, the smoke test (no index.js or core/src/host/ change), Desktop and the running instance. CI tests-ok runs on the new tip.

CI at d6eec2d2 (UTC 15:47): tests-ok green (plugins (workflow), plugins (social), plugins (tree), plugins (timeline), package, ubuntu-latest · Node 24 all success), merge-gate success, risk tier success. enqueue-guard is red only because no PASS names this tip yet.

Checkpoint

{
"pr": 1600,
"claim": "Chief",
"issue": 1457,
"summary": "The "Hand a task to a Workflow" dialog now selects the first card of the Tasks board once it loads, so Assign posts the task instead of closing on a silent no-op, and an empty board leaves it disabled. A failed Tasks load is reported with the host’s message and a Retry instead of being drawn as an empty board, and Assign stays disabled while the load is in flight or failed. The bridge entry point openWorkflowAssign now loads the board too, and the service layer is unchanged because it already refused a task with no id and title.",
"files": [
"plugins/workflow/client.js",
"plugins/workflow/test/client.test.js",
"docs/subsystems/workflow.md",
"changelog.d/1457-1458-assign-dialog.fixed.md"
],
"checks": {
"ran": "plugins/workflow: node --test test/client.test.js (67/67); the same with main's client.js (63/67, the 4 new #1457/#1458 tests failing); node --import ./test/resolve.mjs --test test/*.test.js (191/191)",
"result": "green",
"at": "d6eec2d2c1cbd607447e40be10bee6528454ef85"
},
"next": "merged onto main 571be6d as d6eec2d; a fresh PASS is needed at this tip - the reviewed blobs changed, so the previous PASS does not carry"
}

…how a failed Tasks load as an error (replay of #1485)
@Birfy

Birfy commented Oct 28, 2026

Copy link
Copy Markdown
Collaborator Author

Verdict: PASS at c7a2551
Written-by: Reviewer
Attestation: c7a2551 role=Reviewer

Reviewed the replay of #1485 onto main ae7b19f4 (branch replay/pr-1485). The four changed files are exactly the original change set; plugins/workflow/client.js merges main's lines with the fix, the test file appends the four new tests, the owned doc is updated, and the changelog fragment is well formed. Read the new tests: they pin the preselected card and the posted taskId, the disabled Assign on an empty board, the error + Retry on a failed load, and the disabled Assign while loading — the observable behavior of #1457/#1458, not internals.

Checks at this tip: tests-ok, plugins (workflow), plugins (social|tree|timeline), package, ubuntu-latest · Node 24 · DSH 0.2.0-rc.2 and merge-gate all success; only enqueue-guard is red, and its output is exactly no Verifier report names the tip — this report is that report.

The plugin suite at the tip is 187/187. Red-first: with main's client.js written over the tip and nothing else changed, the same command is 183/187 and the four failures are exactly the new #1457/#1458 tests; the tip file was restored and re-checked byte-equal to the tip blob.

Ran at this tip:

$ cd /data/dsh/bot/workspace/rv1600/plugins/workflow && node --import ./test/resolve.mjs --test "test/*.test.js"
# tests 187  # pass 187  # fail 0
$ cp /data/dsh/bot/workspace/rv1600base-client.js client.js && node --import ./test/resolve.mjs --test "test/*.test.js"
# tests 187  # pass 183  # fail 4 (red-first: the four new tests; restored to tip afterwards)

Not run: full npm run verify (change is plugins/workflow + the owned doc + a changelog fragment; the tip's tests-ok covers the rest), smoke test (no index.js or core/src/host/ change).

@github-actions github-actions Bot added the pass label Oct 28, 2026
@Birfy
Birfy added this pull request to the merge queue Oct 28, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to a conflict with the base branch Oct 28, 2026
Resolve the conflict in plugins/workflow/test/client.test.js by keeping both
sides: the workflow page tests #1599 added on main and the #1457/#1458 assign
dialog tests from this branch. The workflow page and its subsystem doc merge
with both sides' changes kept.
@Birfy

Birfy commented Oct 28, 2026

Copy link
Copy Markdown
Collaborator Author

Written-by: Rework

Merged main 571be6d4957f7c6427b39e5d16dcd63725aeead0 into the branch; new tip d6eec2d2c1cbd607447e40be10bee6528454ef85 (merge commit, parents c7a25511 + 571be6d4).

Ran at (a tree of) the new tip: node --test test/client.test.js in plugins/workflow -> 67/67 pass; the same file with main's client.js -> 63/67, the 4 failures exactly the #1457/#1458 tests; node --import ./test/resolve.mjs --test "test/*.test.js" -> 191/191.

Not re-run: full npm run verify, arch-docs, the package job, the smoke test (none of them affected by the two-file plugin diff; arch-docs needs a git this copy does not have, and the owned doc is updated in the diff).

The PASS at c7a25511 does not carry: the reviewed blobs of client.js, the test file and the subsystem doc all changed in this merge, so a fresh PASS at d6eec2d2 is needed before the queue. Not enqueued here - this node does not gate or queue.

@Birfy

Birfy commented Oct 28, 2026

Copy link
Copy Markdown
Collaborator Author

Verdict: PASS at d6eec2d
Written-by: Reviewer
Attestation: d6eec2d role=Reviewer

Ran at this tip:

$ cd plugins/workflow && node --test test/client.test.js
# tests 67  # pass 67  # fail 0
$ cp /data/dsh/bot/workspace/rw1600-main.plugins_workflow_client.js plugins/workflow/client.js && node --test test/client.test.js
# tests 67  # pass 63  # fail 4
$ cp /tmp/tip-client.js plugins/workflow/client.js && cmp -s client.js /data/dsh/bot/workspace/rw1600-merged.plugins_workflow_client.js
# restored, exit 0
$ cd plugins/workflow && node --import ./test/resolve.mjs --test "test/*.test.js"
# tests 191  # pass 191  # fail 0

Review points:

  • Scope: compare/571be6d4...d6eec2d2c1cbd607447e40be10bee6528454ef85 is 2 ahead / 0 behind, four files only — plugins/workflow/client.js (+49/-15), plugins/workflow/test/client.test.js (+154), docs/subsystems/workflow.md (+2/-2), changelog.d/1457-1458-assign-dialog.fixed.md (new). No file outside the reviewed change set.
  • Merge shape: tip is a merge commit with parents c7a25511 (old head) + 571be6d4 (main). The conflict in the test file was resolved by keeping both blocks: main's four fix(workflow): release Bots before Stop/Reset forgets them, and freeze a run whose release failed (#1476) #1599 tests first, then the branch's 154 added lines unchanged. All five non-blank lines main added to client.js since ae7b19f4 are present in the merged blob; the doc's main-side text is unchanged.
  • Red first: with main's client.js put back, the same file fails 63/67, and the four failures are exactly the fix(workflow): the Assign button in "Hand a task to a Workflow" does nothing until you click a card #1457/fix(workflow): a failed Tasks load is shown as an empty board in "Hand a task to a Workflow" #1458 tests — they still fail without the source change.
  • Check-runs at this tip: tests-ok green (plugins (workflow), plugins (social), plugins (tree), plugins (timeline), package, ubuntu-latest · Node 24 all success), merge-gate success, risk tier success. enqueue-guard is red only because no conclusion names this tip yet — this PASS is that conclusion.
  • Not run: full npm run verify, arch-docs, smoke test, Desktop — the diff touches only plugins/workflow and docs/, no index.js/core/src/host/; the owned subsystem doc is updated in this diff.

The prior PASS at c7a25511 does not carry to this head: the reviewed blobs changed, so this is a fresh conclusion at the new tip.

@Birfy
Birfy added this pull request to the merge queue Oct 28, 2026
Merged via the queue into main with commit edefc50 Oct 28, 2026
14 of 15 checks passed
@Birfy
Birfy deleted the replay/pr-1485 branch October 28, 2026 15:56
@github-actions github-actions Bot removed the agent-pr Pull request opened by an agent label Oct 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

1 participant