test(desktop): settle transcript scroll extremes - #4150
test(desktop): settle transcript scroll extremes#4150orangeCatDeveloper wants to merge 1 commit into
Conversation
bc02dfb to
fb21b8a
Compare
fb21b8a to
4a56b44
Compare
A single scrollTop assignment can leave the scroller 2982px above the bottom, so the virtual window ends seven turns short and the tail turn never mounts. Re-scroll until a painted frame agrees it is at the end. Generated-by: Claude Code
4a56b44 to
04f692b
Compare
|
Closing: the mechanism this change works around was replaced on The review is right that the base was stale, and it turns out to matter more than a rebase. Measurements, all on GitHub-hosted All three failures on the old base reported the same state, from an observation-only diagnostic on the assertion: Every turn was loaded; the scroller sat 2982px above the bottom after a single Worth stating plainly: three-of-thirty against zero-of-thirty is not significant on its own (Fisher exact, p ≈ 0.23). It is the same evidence strength this PR was claiming for its own fix, so it does not prove the refactor fixed the flake either. What decides it is that the code this PR reasons about is gone, and the reworked transcript shows no failure of any spec in thirty runs. If the assertion flakes again, the fastest way back to a cause is a temporary diagnostic in place of the bare count, reporting mounted window, distance from the bottom, and loaded turn count. That is not worth carrying for a failure that is not currently occurring, so it is not being split out. On the other two points: inline issue references would have been fixed — thanks for catching that. The |
Summary
prompt-rail.spec.tsintermittently fails on CI atevicting a turn-owned sibling interaction hands focus back to the transcript:turn-prompt-rail-120is expected to be mounted after scrolling to the bottom, and the locator resolves to zero for the full ten-second poll. It has failed onmain— most recently at01369b082, the commit this branch is based on.scrollTranscriptToassignedscrollToponce. Measured on the runner, that single assignment can leave the scroller 2982px above the bottom while every turn is already loaded, so the virtual window ends seven turns short of the tail and the awaited turn never mounts. The failing state is identical on every occurrence:#3863added a one-shotscrolldispatch plus two painted frames here, which cannot help when the layout keeps growing past them.The helper now re-scrolls until a painted frame agrees the scroller is at the requested extreme. It is split rather than changed in place, because its callers want opposite things:
settleTranscriptAtExtremeis used where a test needs to actually be at an extreme, whilescrollTranscriptOncekeeps the single jump for the focus-handback test, which deliberately jumps once so a late scroll-anchor restore stays observable — a retrying helper would fight that restore and turn the#3121regression into a false pass.The assertion also reports the scroll offset, mounted window and loaded turn count on failure, so a future CI-only failure names its own cause instead of saying only that a turn is missing.
Test-only. No renderer or virtualizer behavior changes.
Verification
Thirty full-suite runs per side on GitHub-hosted
ubuntu-latest, the same runner class that produces the failure. Both sides carry the same probe workflow; apart from it the two trees differ only by this commit.All three
beforefailures reported the same state, quoted under Summary.Two limits worth stating. Three-of-thirty against zero-of-thirty is not statistically significant on its own (Fisher exact, p ≈ 0.23); the argument rests on the measured mechanism, with the rates as corroboration. And
partial-history-notice.spec.ts:59is an unrelated flake that this change does not address — its zero on theafterside is sampling, not a fix.AI use
Select exactly one:
Tool(s) and scope: Claude Code reproduced the failure, took the measurements above, wrote the change, and prepared this PR description.
Checklist
The first box is deliberately unchecked. The change is itself a test, and the failure it removes is a race that appears in roughly one CI run in ten rather than on demand; the before/after measurement above stands in for a deterministic red run.
Does this PR entail a change in behavior?