The browser suite intermittently fails remote messages keep a live channel pinned without unread UI in tests/e2e/chat.spec.ts. The failure is the absence of paused live message 4 at line 2239 after the preceding paused-frame message was visible.
Observed on PR #204 at 1ba373e7990efa58a2ec7bef4169556beb299f4c: first CI attempt passed 256 tests and failed this one. The full browser job passed on the unchanged second attempt. No timeout, assertion, or retry-policy changes were made to obtain that result.
The test reaches the live edge, appends a large message from another user, pauses new animation-frame callbacks, and then appends two further messages separately. Each must reach the DOM before the next is sent, so one fetch containing both cannot mask blocked ingestion.
Local evidence so far:
- The same scenario passed five runs with the fixture CLI invoking the already-built server binary. This avoided a local
go run filesystem stall before the browser scenario; it did not change the browser assertions.
- Twelve instrumented baseline append pairs passed normally, and twelve passed with 6× CPU throttling. Native resize/scroll traces showed recalculated bottom positions before the following scroll callbacks in those runs.
- The scroll component and affected event-ingestion path were unchanged by the password feature. No authentication failure was observed in this test.
- Virtua 0.50.6 reports both user and programmatic movement through
onscroll(offset), and its imperative target follows resize measurements for a short interval. That is relevant context, but does not establish the cause of this CI failure.
The missing-message root cause remains unknown. Preserve the failing browser's DOM/error context, WebSocket event order, message fetches, and native scroll/resize ordering on a recurrence. Distinguish an event not being fetched from a fetched message being virtualized out of the DOM or a follow-state transition.
A separate investigation reproduced an unfinished follow-to-bottom command overriding a real upward wheel scroll after frames resume. That adjacent command-lifetime defect should be repaired with its own before/after proof; it is not yet evidence that the missing-message failure above has the same cause.
The browser suite intermittently fails
remote messages keep a live channel pinned without unread UIintests/e2e/chat.spec.ts. The failure is the absence ofpaused live message 4at line 2239 after the preceding paused-frame message was visible.Observed on PR #204 at
1ba373e7990efa58a2ec7bef4169556beb299f4c: first CI attempt passed 256 tests and failed this one. The full browser job passed on the unchanged second attempt. No timeout, assertion, or retry-policy changes were made to obtain that result.The test reaches the live edge, appends a large message from another user, pauses new animation-frame callbacks, and then appends two further messages separately. Each must reach the DOM before the next is sent, so one fetch containing both cannot mask blocked ingestion.
Local evidence so far:
go runfilesystem stall before the browser scenario; it did not change the browser assertions.onscroll(offset), and its imperative target follows resize measurements for a short interval. That is relevant context, but does not establish the cause of this CI failure.The missing-message root cause remains unknown. Preserve the failing browser's DOM/error context, WebSocket event order, message fetches, and native scroll/resize ordering on a recurrence. Distinguish an event not being fetched from a fetched message being virtualized out of the DOM or a follow-state transition.
A separate investigation reproduced an unfinished follow-to-bottom command overriding a real upward wheel scroll after frames resume. That adjacent command-lifetime defect should be repaired with its own before/after proof; it is not yet evidence that the missing-message failure above has the same cause.