The packets page defaults to a 15-minute time window (public/packets.js, savedTimeWindowMin, falling back to 15 when localStorage.meshcore-time-window is unset). CI freshens the fixture at the start of the job so its newest packet is "now", then the Playwright step runs for a quarter of an hour or more. Any suite that reads packet rows and does not pin the window therefore depends on reaching its position in the list before the fuse burns down.
31 wired suites navigate to #/packets. Five pin meshcore-time-window:
test-e2e-playwright.js
test-issue-1281-location-row-e2e.js
test-issue-1692-packets-init-parallel-e2e.js
test-issue-1799-label-vocab-e2e.js
test-observer-iata-1188-e2e.js
The other 26 inherit the 15-minute default. Most pass today because they sit early in the list, or because they assert on chrome (nav, layout, gestures) rather than on rows, so an empty table does not fail them. That is luck, not design, and it is luck that changes whenever a suite is added, reordered, or slows down.
How it surfaced
tests/e2e/test-packets-scope-column.js was one of the unrun suites from #2037. It passed twice on a branch, then failed three consecutive runs on the same code with:
Error: packets table never produced a row with td.col-type:
{"table":true,"rows":1,
"firstRowHtml":"<td colspan=\"12\" class=\"text-center text-muted\" ...>No packets found</td>",
"tableClass":"data-table hide-col-region"}
What changed between the passing and failing runs was not the code: #2053 wires in nine more suites, which moved this one later in the list, past 15 minutes. It also explains the intermittent 4-passed-3-failed I recorded during the #2037 triage on 2026-09-18 and wrongly wrote off as "something has since fixed it". It was never fixed and never broken.
Pinning the window in that one suite is in #2053. This issue is about the other 26.
Options
- Pin per suite. Set
meshcore-time-window alongside the other localStorage setup each suite already does. Explicit, 26 small edits, and each suite states the assumption it relies on.
- Pin once, centrally. Give the E2E step a helper the suites call, or seed the value through an
addInitScript in a shared context factory. Fewer edits, but the suites stop saying what they depend on.
- Re-freshen the fixture mid-job. Keeps the default path under test, which is worth something: today no suite exercises what a visitor with the default window actually sees. It does mean restarting or reloading the server mid-step.
I would take 1 for suites that assert on rows and leave the chrome-only ones alone, plus one suite that deliberately keeps the default and asserts the empty state renders correctly. But this is a call about what the E2E job is for, so it wants an opinion before 26 files are touched.
Not investigated
Whether any current intermittent failure elsewhere in the job has this same cause. Given the signature is "assertion about missing rows, only sometimes", it is worth checking against the flakes already on record before attributing them to anything else.
The packets page defaults to a 15-minute time window (
public/packets.js,savedTimeWindowMin, falling back to 15 whenlocalStorage.meshcore-time-windowis unset). CI freshens the fixture at the start of the job so its newest packet is "now", then the Playwright step runs for a quarter of an hour or more. Any suite that reads packet rows and does not pin the window therefore depends on reaching its position in the list before the fuse burns down.31 wired suites navigate to
#/packets. Five pinmeshcore-time-window:The other 26 inherit the 15-minute default. Most pass today because they sit early in the list, or because they assert on chrome (nav, layout, gestures) rather than on rows, so an empty table does not fail them. That is luck, not design, and it is luck that changes whenever a suite is added, reordered, or slows down.
How it surfaced
tests/e2e/test-packets-scope-column.jswas one of the unrun suites from #2037. It passed twice on a branch, then failed three consecutive runs on the same code with:What changed between the passing and failing runs was not the code: #2053 wires in nine more suites, which moved this one later in the list, past 15 minutes. It also explains the intermittent 4-passed-3-failed I recorded during the #2037 triage on 2026-09-18 and wrongly wrote off as "something has since fixed it". It was never fixed and never broken.
Pinning the window in that one suite is in #2053. This issue is about the other 26.
Options
meshcore-time-windowalongside the otherlocalStoragesetup each suite already does. Explicit, 26 small edits, and each suite states the assumption it relies on.addInitScriptin a shared context factory. Fewer edits, but the suites stop saying what they depend on.I would take 1 for suites that assert on rows and leave the chrome-only ones alone, plus one suite that deliberately keeps the default and asserts the empty state renders correctly. But this is a call about what the E2E job is for, so it wants an opinion before 26 files are touched.
Not investigated
Whether any current intermittent failure elsewhere in the job has this same cause. Given the signature is "assertion about missing rows, only sometimes", it is worth checking against the flakes already on record before attributing them to anything else.