Flaky: the Activity feed keyboard-scroll test reads the wrong first row in view #1006

Activity

1. V3RON

   added

   bug:newReported. An agent may triage it (rule 8), and nothing more.Reported. An agent may triage it (rule 8), and nothing more.

   flaky-testNames a test that fails without a code change. Delivery skips its base-commit check.Names a test that fails without a code change. Delivery skips its base-commit check.

   on Oct 25, 2026
2. V3RON

   self-assigned this

   on Oct 25, 2026
3. V3RON commented on Oct 25, 2026

   

   V3RON

   on Oct 25, 2026

   ContributorAuthor

   More actions

   Reproduction

   This is a defect in the test, not in the console. It notes the row in view before the history's end row has arrived. When that row arrives late, the feed keeps the reader at the end on purpose and moves the rows by the row's height. That gives the same result CI saw: -51 becomes the next row at -37.

   Branch bug/1006-repro, in e2e/console/activity.spec.ts: "the feed scrolls inside itself with the keyboard, and counts the events that came in while scrolled down". The test holds the real daemon's ?before= answer until after inView is noted, then releases it and waits for "Start of the history (".

   pnpm test:console --project=chromium e2e/console/activity.spec.ts -g "scrolls inside itself"
   
       -   "href": "/activity/evt_e16bb8da-…",
       -   "top": -51,
       +   "href": "/activity/evt_caafad57-…",
       +   "top": -37,
       > 410 |       expect(await firstRowInView(page)).toEqual(inView);
   

   Root cause

   e2e/console/activity.spec.ts:391 (on main) reads firstRowInView as soon as the box reaches its end. The older-page request that useNearEnd sends (ui/src/ds/feed.tsx:158-161) may still be in flight at that point. When it answers, the end row goes below the box and shrinks it. useStayAtEnd (feed.tsx:131-132) then scrolls to the new end, which is the behaviour the test at activity.spec.ts:404 asks for. The rows move by the end row's height: -51 - 46 + 60 = -37. On a loaded runner the answer can come after line 391.

   Simplest fix

   In the test only: release the gate once the box is at its end, wait for "Start of the history (", poll again that the box is at its end, and only then note inView. Keep the gate so the late answer is still forced. Locally this passed 5/5 (--repeat-each 5).

   Alternatives rejected

   • Stop useStayAtEnd moving the rows: this breaks the behaviour the test at line 404 pins.
   • Use PageDown so the reader is not at the end: this needs many more events.
   • Retry the assertion with expect.poll: this hides the move instead of ordering it.

   Risk

   • The fix must keep the gate. Without it, the test goes back to depending on timing.

   Written by an agent.
4. V3RON

   removed their assignment

   on Oct 25, 2026
5. V3RON

   added

   bug:readyAn agent may fix it.An agent may fix it.

   and removed

   bug:newReported. An agent may triage it (rule 8), and nothing more.Reported. An agent may triage it (rule 8), and nothing more.

   on Oct 25, 2026
6. V3RON

   self-assigned this

   on Oct 25, 2026
7. V3RON

   closed this as completedin #1007on Oct 25, 2026
8. V3RON commented on Oct 25, 2026

   

   V3RON

   on Oct 25, 2026

   ContributorAuthor

   More actions

   Delivery run

   Merged: #1007 (#1006)

   Written by an agent.