Settings → Workflows draws a snapshot: a running run never moves until the page is reopened #1810

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 6d058c4c1bc446b5aacbc7f89cc56f39
Branch: dev/3-settings-workflows-poll
Base: 84de666
At: 2026-10-30T07:07:09Z

Symptom

In Settings → Workflows, the flow diagram is a snapshot of the moment the page opened. A run that is running keeps showing running, a queued step keeps showing queued, and when the run ends the chip still does not change — the user has to leave the page and come back to see the new state. On the room side the same data moves every 2 seconds: open the Workflow drawer for that same run and the chips advance on their own.

Root cause

• The page reads once and never again: core/src/client/workflows.js:415-419 is useEffect(() => { ... readWorkflows(invoke).then(...) }, []) — the whole file has no setInterval and no second read path. Afterwards pack only changes when a write operation (rename/delete/run) returns.
• The room side polls the same payload: plugins/workflow/client.js:1902 computes (item.activeCount ?? 0) > 0 and :1906 starts setInterval(() => { if (!gone) void refresh() }, 2000). That is the behaviour users compare Settings against.
• The data is already there: core/src/host/workflow/service.js:326-352 returns, per workflow, activeCount, queueDepth and run: publicRun(...). So this needs no server change, no new endpoint and no new storage — only the page has to ask again.
• Consequence in the UI: bt-wf-chip text is derived from nodeStatus in that one payload, so it is frozen for the lifetime of the page.

Expected

1. While any workflow of the page has activeCount > 0, the page re-reads every 2 seconds (the same predicate and interval the room uses), and the chips follow: a step that goes running → done changes the chip in the next render without leaving the page, and a run that finishes stops showing live work.
2. With every activeCount === 0, the page must not poll: no more than the initial read in 10 seconds.
3. Polling must be suspended while the user is editing (editing === true), so a refresh cannot overwrite or interrupt an in-flight edit.
4. The effect cleans up on unmount: no read after the page is gone.
5. A read that fails during polling goes through the existing error line + Retry, does not throw an unhandled rejection, and does not replace the page with No workflows yet..
6. Stale responses are dropped by the existing gone guard (already present in the mount effect) — a response that arrives after the page changed state must not apply.

Reproduction

Audited by FlyBot Product on 84de6663339ad8773c3f85fb200f0bdbfc6ca724 (live main at the time), read-only:

• grep -n 'setInterval' core/src/client/workflows.js → no match; useEffect appears at :194 (the drawer) and :415 (the page read), the latter with [] deps.
• grep -n 'setInterval\|activeCount' plugins/workflow/client.js → :1902 (item.activeCount ?? 0) > 0, :1906 setInterval(..., 2000).
• By hand: run a workflow whose step takes a few seconds, open Settings → Workflows while it runs, watch the chip stay running past the step's completion, then close and reopen the page: it shows the finished state. The room drawer for the same run advances by itself during the same window.
• A run started after the page is open does not appear at all (no read is made), which is the sharpest form: the page cannot learn that a run exists.

Minimal fix (slice)

core/src/client/workflows.js: one effect in WorkflowsPage with the room's predicate and interval.

• const live = (pack?.workflows ?? []).some((item) => (item.activeCount ?? 0) > 0)
• when live && !editing, setInterval(() => { if (!gone) void readWorkflows(invoke).then((settled) => { if (!gone) apply(settled) }) }, 2000), cleaned up on unmount and whenever live/editing flips;
• reuse the existing gone guard so a late response is discarded;
• no change to plugins/workflow/client.js, the host, the endpoint or the payload.

About 10 lines of source. Because core/src/client/workflows.js is carried by the client bundle, landing this regenerates the 0008 patch (and its files/ mirror) — follow the project's generation rules for the whole chain; no patch is hand-edited.

Prerequisite: the test fixture cannot observe an effect yet (MUST come first)

core/test/workflows-page.test.js:23-28 fakes React with useEffect() {} (a no-op) and useState: (value) => [states.length > 0 ? states.shift() : value, () => {}] (a setter that never re-renders). Today no test in this file can observe an effect or a re-render, so a poll case written against the current fixture would pass no matter what the source does — a guaranteed false green.

Before the fix lands, the fixture has to be able to (a) register and run effects, (b) flush the promises a poll resolves and settle the re-render, and (c) drive and assert timers (fake setInterval, advancing 2 s without sleeping). Roughly 30 lines in the fixture.

Red-first requirement

With the upgraded fixture, the new case must be red on the untouched source (the chip stays at its mount-time text after the run finishes / the second read never happens) and green with the fix. If the red cannot be produced, do not open the PR — that means the case is not observing the effect and the false green is back.

Acceptance

1. New case: mount with a live run, advance the fake clock 6 s → at least two reads observed, and a step whose nodeStatus goes running → done changes the chip text in the same test without remounting.
2. New case: every workflow activeCount: 0 → advance 10 s → exactly one read (the mount one).
3. New case: editing === true → advance 10 s → no new read; leaving editing resumes polling.
4. New case: unmount while polling → advance 10 s → no read after unmount (no leak).
5. New case: a read that rejects during polling → the existing error line + Retry is shown, no unhandled rejection, No workflows yet. is not shown.
6. Existing workflows-page.test.js cases stay green; the fixture upgrade does not change what they assert.
7. npm run verify green at the tip; the patch chain check passes twice with the same output; the client bundle is regenerated, not hand-edited.

Scope

• core/src/client/workflows.js — the poll effect (~10 lines).
• core/test/workflows-page.test.js — fixture upgrade (~30 lines) and the new cases.
• patches/ds-bot/0008-client-bundle.patch + patches/ds-bot/files/** mirror — regenerated by node scripts/ds-bot-patches.mjs generate after npm --prefix core run build; no hand-edited hunks.
• No host change, no endpoint, no docs change beyond what the client bundle already documents.

Out of scope (follow-ups if they matter)

• The room drawer's polling is unchanged.
• The list row badges (P-26) and the failed-run preview (P-28) are separate backlog items.

Duplicate check (GitHub, open and closed, 2026-10-30)

• settings workflows refresh — 4 hits: #1564 (room double-poll, the fix that landed), #1522, #1278, #152 — none is the Settings page.
• workflow stale canvas — 5 hits; settings workflows poll — 3 hits; none names this page's read-once behaviour.
• Backlog: P-98/P-44 are room-side polling, P-26 is list-row badges, P-28 is the failed-run preview — different surfaces.
• No duplicate. This is the Settings surface of the same data the room already polls.