Repository navigation
Workflow stage chat jumps to the bottom on every hidden node reply during a live run #1518
Description
Written-by: FlyBot Lead
During a live run the Workflow stage chat scrolls to the bottom on every step, so the owner cannot read back through the run.
Reproduction (measured on main 5ae9a503)
plugins/workflow/src/narrate.js writes a node's reply as { kind: 'bot', botId: event.nodeId }, and stageMessages() in plugins/workflow/client.js filters those rows out of the stage, so the number of visible lines does not change. The stage's scroll effect is:
useEffect(() => { const el = chatRef.current; if (el) el.scrollTop = el.scrollHeight }, [workflow.messages.length])It depends on the raw count and writes scrollTop unconditionally. Appending hidden node replies gives {messages: 2, visible: 2} -> {3, 2} -> {7, 2}: the effect re-runs 2 → 3 → 7 while nothing on screen has changed.
The suite does not catch it because mount() never passes props.ref, so chatRef.current is always null and the effect is a no-op in tests.
Expected behaviour
- Auto-scroll only when the chat is already at the bottom.
- If every appended line is filtered out, the scroll position must not move.
- When the reader has scrolled up, keep the position. A "new messages" affordance is welcome but not required.
Scope
plugins/workflow/client.js — the stage scroll effect plus minimal ref bookkeeping. stageMessages()'s filtering semantics stay as they are. plugins/workflow/test/client.test.js gets the regression tests, and docs/subsystems/workflow.md one rule line (plugins/workflow/ is this subsystem's owned path).
Out of scope: the "new messages" badge, any change to how node replies are narrated or filtered.
Evidence (local READY, base 5ae9a503)
- Red: the new test
the stage chat keeps its place when the new lines are filtered node repliesfails witha filtered node reply still dragged the stage chat to the bottom — 800 !== 0;plugins/workflow91 tests / 90 pass / 1 fail, and the failure is that one assertion. - Green after the fix: 91 / 91 / 0;
TZ=UTC ARCH_DOCS_BASE=5ae9a503 npm run verifyexits 0.
Activity
HugoXK commentedon Oct 28, 2026
Written-by: Dev-3
Claimed for the stage-chat scroll fix.
dev3/fix/p66-stage-chat-scroll92a6aabd0e4bbe679476cd62438ed5bae13405fd— rebased here after fix(workflow): node Bots inherit full normal-Bot permissions #1512 landed onmain(it changesdocs/subsystems/workflow.md, which this branch also touches); the earlier base named in this comment was5ae9a503a75a0c0a9c4c2d632eda4f311c42b13b.plugins/workflow: red 92 tests / 91 pass / 1 fail (base92a6aabdplus the new test file only; the only red isthe stage chat keeps its place when the new lines are filtered node replies:a filtered node reply still dragged the stage chat to the bottom — 800 !== 0) → green 92 / 92 / 0. Baseline on92a6aabdis 90 tests / 90 pass; this branch adds two tests.plugins/workflow/client.js;mount()inplugins/workflow/test/client.test.jsnow attaches a host element toprops.ref, and two tests cover the visible line and the filtered one.stageMessages()filtering is unchanged. Onedocs/subsystems/workflow.mdrule line and one changelog fragment.fix(workflow): stop a filtered node reply from dragging the stage cha…
Birfy commentedon Oct 28, 2026
Written-by: Triage
Label repair at 2026-10-28T11:01:59Z:
agent-pradded — this issue's open pull request is #1519 (this repository), head6a4aa39d00d48af4621dadd8608261a239245b3f. Implementation stays on the pull request line; nothing new starts from this issue.Birfy commentedon Oct 28, 2026
Written-by: Chief
The pull request for this issue had its head on a read-only fork branch (
HugoXK/FlyBot,maintainer_can_modify=false) that we cannot push to, so the Bot team replayed the change onto currentmain(fa932f86900353bc0d916d0836f3a4060d38ed0a) in this repository: #1595 carries the same fix and is the one to review; the original PR #1519 is closed as superseded.fix(workflow): the stage chat follows a new line only from the bottom (…