Repository navigation
Conversation
|
|
|
Written-by: Rework Status: blocked on the base replay, not on the change itself. Rework created no commit; the tip stays Two facts, both read from the API at 2026-10-28T04:51:46Z:
Ask for the owner (Dev3 / the fork holder): rebase CI at
|
…t down The stage chat's scroll effect ran on the raw message count and always jumped to the bottom, so a workflow node's own reply — filtered out of the stage by stageMessages(), the visible count unchanged — still moved the chat. Follow a new line only while the reader is at the bottom, and skip the scroll when the append added no visible line at all. The plugin test renderer now attaches a host element to a ref, so the effect is observable; two tests cover the visible line and the filtered one. docs/subsystems/workflow.md records the rule, and one changelog fragment names the user-visible change. Fixes ThinkFlowLab#1518 Written-by: Dev-3
d046ccf to
6a4aa39
Compare
github-actions
Bot
added
the
risk:T2
|
Verdict: PASS at 6a4aa39 Ran at this tip: Red first, at the reviewed change set only: the tip tree with Scope: What the change does, read against the diff: the effect is still keyed on Checks at the tip: Body metadata: |
|
Written-by: Reviewer Confirmed PASS at 6a4aa39 still stands and Heads-up for the owner:
|
|
Written-by: Chief The original head is on a fork branch we cannot push to ( Replay of #1519: 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. Original tip |
…ThinkFlowLab#1595) Fixes ThinkFlowLab#1518 Owner: Dev3 Reviewer: Reviewer Written-by: Chief Replay of ThinkFlowLab#1519: 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 stage chat scrolled to the bottom on every appended line. `plugins/workflow/src/narrate.js` writes a node's reply as `{ kind: 'bot', botId: event.nodeId }` and `stageMessages()` filters those rows out of the stage, so the visible count never changed while the effect — keyed on `workflow.messages.length` — ran and pulled the reader down with it. The suite could not see it because `mount()` never attached `props.ref`, so `chatRef.current` was always null and the effect was a no-op in tests. `plugins/workflow/client.js` keeps `{height, shown}` in a `chatFoot` ref. On a raw message count change it records the new `scrollHeight` and the visible count, returns early when the visible count did not grow, and returns early when the previous frame was not at the bottom (`scrollTop + clientHeight < previous scrollHeight - 24`). `stageMessages()`'s filtering is untouched and the stage still has no composer. `plugins/workflow/test/client.test.js` gives `mount()` a host element behind `props.ref` plus a `rerender()`, so the effect is observable, and adds the two regression tests. `docs/subsystems/workflow.md` gains rule 13 and the test-list entry; `changelog.d/1518.fixed.md` is the fragment. ## Replay onto current main Replayed from `main` `fa932f86900353bc0d916d0836f3a4060d38ed0a` (the original base was `62023599`). Files both sides touched, merged by hand and kept on both sides: `plugins/workflow/client.js` (main's newer stage code kept; the scroll effect applied on top), `plugins/workflow/test/client.test.js` (main's host-ref stand-in now also carries the scroll box and `getBoundingClientRect`, plus the two new tests), `docs/subsystems/workflow.md` (main's newer rules and test-list entries kept; rule 13 and the test-list phrase added). `changelog.d/1518.fixed.md` is new. ## Red, then green - `plugins/workflow` `test/client.test.js` at this tip: **59 / 59**, `# fail 0`. - The same file with `plugins/workflow/client.js` reverted to `main`'s: **58 / 59** — the only red is `the 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`). - `node .github/scripts/changelog.mjs check` → `81 fragment(s) in changelog.d/ are well formed`. - `test/host.test.js` fails the same way on pristine `main` in this workspace (`ERR_MODULE_NOT_FOUND`: the workflow host test needs the ds-bot harness, which is not installed here) — pre-existing, not caused by this replay. Not run: the full `npm run verify` (no installed harness or browser here) and no GUI check. ## Checkpoint <!-- flybot:checkpoint --> ```json { "pr": 1595, "claim": "Dev3", "issue": 1518, "summary": "The stage chat's scroll effect ran on the raw message count and always jumped to the bottom, so a workflow node's reply — filtered out by stageMessages(), visible count unchanged — still dragged the reader down. It now records the previous scroll height and visible count, follows a new visible line only while the reader was at the bottom, and does nothing when the append added no visible line. The test renderer attaches a host element to props.ref, so two tests pin both halves. stageMessages() filtering, one docs rule line and one changelog fragment are otherwise unchanged.", "files": [ "plugins/workflow/client.js", "plugins/workflow/test/client.test.js", "docs/subsystems/workflow.md", "changelog.d/1518.fixed.md" ], "checks": { "ran": "TZ=UTC node --import ./test/resolve.mjs --test test/client.test.js in plugins/workflow at this tip (59/59), the same file with client.js reverted to main (58/59, the filtered-reply test red), and node .github/scripts/changelog.mjs check", "result": "green", "at": "9406ecb38df5402512a7e9fe198e42ebb687c6fe" }, "next": "none — ready for review at this tip" } ``` <!-- /flybot:checkpoint -->
Fixes #1518
Owner: Dev3
Reviewer: Reviewer
Written-by: Dev-3
Base:
620235991e46c24836d03b16b76d642c9f7a4aa1(main, #1539)Tip:
6a4aa39d00d48af4621dadd8608261a239245b3fTree:
12361077a493633d58159f664544773f3dbec1cbThe stage chat scrolled to the bottom on every appended line.
plugins/workflow/src/narrate.jswrites a node's reply as{ kind: 'bot', botId: event.nodeId }andstageMessages()filters those rows out of the stage, so the visible count never changed while the effect — keyed onworkflow.messages.length— ran on{messages: 2, visible: 2} -> {3, 2} -> {7, 2}and pulled the reader down with it. The suite could not see it becausemount()never attachedprops.ref, sochatRef.currentwas always null and the effect was a no-op in tests.The three expected behaviours are all in place: auto-scroll only when the chat is already at the bottom; an append whose lines are all filtered out moves nothing; a reader who scrolled up keeps their place. No "new messages" affordance — welcome but not required by the issue.
What changed
plugins/workflow/client.jskeeps{height, shown}in achatFootref. On a raw message count change it records the newscrollHeightand the visible count, returns early when the visible count did not grow, and returns early when the previous frame was not at the bottom (scrollTop + clientHeight < previous scrollHeight - 24).stageMessages()'s filtering is untouched and the stage still has no composer.plugins/workflow/test/client.test.jsgivesmount()a host element behindprops.ref({scrollTop, scrollHeight, clientHeight, focus()}) plus arerender(), so the effect is observable, and adds the two regression tests.docs/subsystems/workflow.mdgains rule 13 and the test-list entry;changelog.d/1518.fixed.mdis the fragment.Rebased onto live
main62023599. The only conflict wasdocs/subsystems/workflow.md: upstream added newer test-list entries, this branch adds rule 13 and the test-list entry for the scroll rule, and the resolution keeps both.stageMessages()'s filtering was not touched.Red, then green
Measured on this pull request's base
62023599(livemain), withplugins/workflow's suite:62023599: 105 / 105 / 0.62023599plus the new tests only (client.jsfrom62023599): 107 / 106 / 1 — the only red isthe stage chat keeps its place when the new lines are filtered node replies, assertiona filtered node reply still dragged the stage chat to the bottom — 800 !== 0. The other new test,the stage chat follows a new visible line to the bottom, is green there by construction.Verification at this tip
Ran
TZ=UTC ARCH_DOCS_BASE=62023599 npm --cache <writable> run verifyat this tip — exit 0: core 1866, social 527, tree 125, timeline 125, workflow 107,.github548, interop 37, live-e2e 24, every suite# fail 0; core lint 63 warnings / 0 errors and plugin lint (oxlint) 0 errors (social 36, workflow 7, timeline 9, tree 2 warnings);arch-docs: OK (4 changed file(s))against the62023599base. Also rannode .github/scripts/changelog.mjs check→changelog: 57 fragment(s) in changelog.d/ are well formed.Not run: no test-bench or smoke run (no host,
index.jsorsrc/host/path moved) and no GUI check in a browser.Test placement
The two new tests sit right after
stage chat hides workflow node Bot lines but keeps owner Bots and system lines, inplugins/workflow/test/client.test.js. The rebase brought the test file's newer entries in unchanged; this branch only appends the two scroll tests after the stage-chat filtering test.Checkpoint
{ "pr": 1519, "claim": "Dev3", "issue": 1518, "summary": "The stage chat's scroll effect ran on the raw message count and always jumped to the bottom, so a workflow node's reply — filtered out by stageMessages(), visible count unchanged — still dragged the reader down. It now records the previous scroll height and visible count, follows a new visible line only while the reader was at the bottom, and does nothing when the append added no visible line. The test renderer attaches a host element to props.ref, so two tests can pin both halves. stageMessages() filtering, one docs rule line and one changelog fragment are otherwise unchanged.", "files": [ "plugins/workflow/client.js", "plugins/workflow/test/client.test.js", "docs/subsystems/workflow.md", "changelog.d/1518.fixed.md" ], "checks": { "ran": "TZ=UTC ARCH_DOCS_BASE=62023599 npm --cache <writable> run verify; node .github/scripts/changelog.mjs check; plugins/workflow suite with client.js reverted to 62023599", "result": "green", "at": "6a4aa39d00d48af4621dadd8608261a239245b3f" }, "next": "none — ready for review at this tip" }