flaky(e2e): pinned tail can load earlier history after its settle check

[M4n5ter]

What happened

The Desktop E2E test following the tail does not ask for the history above it (apps/desktop/e2e/transcript-scroll.spec.ts:712) intermittently loads an earlier transcript range after its readiness check has already declared the pinned tail settled.

Observed in PR #4649 CI run 33827319970, attempt 1:

Expected: "turn-fixture-1"
Received: "turn-prompt-rail-111"
at apps/desktop/e2e/transcript-scroll.spec.ts:746

The test records the first loaded Turn, resizes the viewport, polls until the transcript is both at the tail and inside the earlier-history load band, waits 12 painted frames, and then expects the first loaded Turn to remain unchanged. Under the four-worker Linux/Xvfb CI load, the first Turn changed anyway. That means an earlier-range request was either already admitted before the geometry poll returned or was admitted after the state the poll observed.

This failure is unrelated to the PR under test: #4649 does not change transcript scrolling, paging, or this E2E spec. The other 105 E2E tests passed. Rerunning the failed CI job was requested separately.

Expected behavior: while the transcript is following its tail, entering the geometric load band because of viewport/layout changes must not be interpreted as reader intent to load earlier history.

How to reproduce

Intermittent under CI load:

1. Run the Desktop E2E suite on Linux/Xvfb with four workers.
2. Observe following the tail does not ask for the history above it after the prompt-rail fixture viewport grows to 900×1500.

The failure was observed once in 110 tests on the run linked above. A deterministic reproduction has not yet been established.

Environment

• Maka commit: fbbc141be (PR fix(desktop): restore retained shared sessions #4649; based on b39e8d36e)
• OS: GitHub-hosted Linux runner with Xvfb
• Surface: Desktop E2E
• Topology: 4 Playwright workers

Logs, screenshots, or additional context

This is not covered by the nearby open timing reports:

• flaky(e2e): prompt-rail:370 re-reads the rail after the poll that settled it #4675 / test(desktop): settle the prompt rail across two consecutive reads #4685 concern prompt-rail state changing after a rail snapshot.
• flaky(e2e): transcript-scroll:498 asserts the tail before a viewport change re-pins it #4648 concerns a one-shot tail-distance precondition in another transcript-scroll case.
• flaky(e2e): nested-scroller test samples the second tail follow before it settles #4688 concerns the second tail-follow after a nested-scroller test receives an answer.

The test's current geometry poll was added in #4386. It proves one sampled state is at the tail and in the load band, but it does not prove that no earlier-range request is already admitted or becomes admitted by the subsequent scroll/resize delivery. Investigation should observe the actual transcript-page request boundary, rather than add another fixed frame delay. If a request is emitted while the scroll authority is still pinned, fix the product ordering; if the request predates the stable state legitimately, make the test synchronize with that admitted work before recording its baseline.

[M4n5ter]

Investigation update (2026-09-04):

• CI attempt 2 failed at the identical assertion with the identical turn-fixture-1 → turn-prompt-rail-111 transition. A third failed-job rerun is now queued.
• The exact PR base (main at b39e8d36e) passed its hosted CI run, so this is not yet evidence that the assertion is universally broken on Linux.
• On the PR head, the target test passed 20/20 in isolation with four workers, the adjacent history asked for at the very top + target sequence passed 20/20 with one worker, the entire transcript-scroll spec passed 11/11 with four workers, and the target also passed in a complete 110-test local run.
• Trace timing from both hosted failures shows the geometry poll observing a settled pinned tail before the earlier range appears. The likely seam is delayed viewport/scroll delivery being classified as reader intent; the actual range request boundary still needs instrumentation before calling that root cause proven.

Correction to the initial report: #4649 does not modify the scroll authority, paging trigger, or this test, so this looks like a pre-existing timing defect exposed by scheduling. However, because both hosted attempts failed while the base run passed, “unrelated to the PR” should be treated as an inference rather than a proven fact until the request boundary is observed or the rerun succeeds.

[M4n5ter]

Final rerun result: attempt 3 of the unchanged PR head passed the complete CI job, including all Desktop E2E tests on Linux/Xvfb. This confirms the failure is rerun-recoverable and supports tracking it as an independent timing flake rather than changing #4649.

[Astro-Han]

Closing: the test this reports no longer exists.

#4741 removed transcript-scroll.spec.ts in full — 22 tests across it and prompt-rail.spec.ts, which together held four of the five open flake reports. They assert scroll geometry against a compositor that settles on its own schedule: that needs a real layout engine, not Electron, and under four-worker Xvfb load the suite read a scroller mid-settle and blocked changes that never touched scrolling.

Coverage was deleted, not moved. The rebuild belongs one tier down — Storybook + Chromium for geometry — and is being worked out in #4727. retries: 0 is unchanged.

Reopening is the right call if the rebuild lands somewhere this report still applies to.