Repository navigation
test: keep the held sidebar preferences read alive on slow runners - #1020
Conversation
The session-change test holds the secondary sidebar-preferences decode across several UI steps, but the app aborts preference reads after 10s. On slow WebKit runners those steps exceed the budget, the read is aborted, and the test fails at the busy assertion or while waiting for the released response. Disable app timeouts for this page so the test, not the runner's speed, decides when the read completes. Co-authored-by: Carl <32a2e2c9d428ee08902cab75d956da2c1d235a22d4766b0dd4138bf6e2e5db1d@buzz.block.builderlab.xyz> Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: Wes <[email protected]>
wesbillman
left a comment
wesbillman
left a comment
There was a problem hiding this comment.
🤖 Carl, an automated reviewer, commenting via Wes's GitHub account.
Verdict: no blockers. Not approving; that's Wes's call.
The diagnosis checks out. The preference read combines AbortSignal.timeout(10_000) in src/features/relay/session.ts:1179-1183. The cited WebKit failure in run 38483569748 fails at aria-busy (sidebar-unread.spec.mjs:478) after the 10 s expect wait, which matches a held read that got aborted. The addInitScript override is installed before open(), so it covers the session's signal. The roster-reveal budget this test asserts uses setTimeout (useSidebarStartup.ts:60), so the override doesn't touch it.
Considered and accepted: the override disables every AbortSignal.timeout on this page, not just the preference read. Narrowing it by matching ms === 10_000 would tie the test to a magic number for no real gain. The worst case is that an unrelated hang in this test hits the 120 s test timeout instead of an app timeout error.
Validation: CI is green on ade4b4c except JavaScript (2/2), which is still running, and that includes Flake check (webkit) and Flake check (chromium). No local run, since CI and the PR's fail-then-pass evidence cover this.
) Signed-off-by: Wes <[email protected]>
…al-divider * origin/main: (70 commits) feat(inbox): archive conversations and reopen on incoming activity (#677) test: wait for keyboard initial focus in agent activity popups (#1019) test: keep the held sidebar preferences read alive on slow runners (#1020) Polish channel and thread join previews (#828) refactor: share the Buzz base prompt and core memory reads across agent plugins (#1008) Continue Me chats as one top-level conversation for native agents (#1000) feat(release): enable automatic updates for Windows and Linux previews (#1004) fix: keep the video fullscreen button clickable above inline controls (#1007) Cmd/Ctrl+W only closes tabs; add Ctrl+Tab tab switching (#936) Polish workspace surfaces, split controls, and emoji composition (#801) fix: wake reading after an exact message reveal (#1006) feat(pairing): copy the pairing code from Settings (#1003) Ignore .scratch in the Vite dev watcher (#1001) fix(client): recover websocket connections across repeated rollouts (#996) test: fix six cross-branch CI flakes (#1002) feat(agents): run Buzz's own copies of Claude and Codex, kept on the latest release (#949) ci: repeat changed Vitest and Playwright tests 10x on pull requests (#890) feat(agents): restore agent memory (#982) Soften compact dropdown outlines (#991) fix(agents): manage providers, models, and agent migrations (#952) ... Signed-off-by: morgmart <[email protected]> # Conflicts: # src/features/messages/Messages.module.css
Fixes the WebKit flake in
sidebar-unread.spec.mjs› "session changes discard the previous sidebar targets and manual unread still participates". It failed twice onmaintoday: run 38483569748 ataria-busyand run 38481637023 atwaitForResponse.Cause
The test holds the secondary community's
sidebar-preferencesdecode, then switches communities, opens channel details, marks the channel unread, scrolls, and finally releases the decode. The app gives each preference read a 10 s budget (AbortSignal.timeout(10_000)insrc/features/relay/session.ts). On slow runners, the steps between the switch and the release take longer than that. In the failing CI trace, the held request is aborted after 9.8 s, about 0.3 s before thearia-busyassertion. Once the read is aborted, preferences settle as an error, so the sidebar is never busy. And if the abort lands later,route.continue()never produces the response the test is waiting for. Passing runs of this test already took up to 21 s, so the margin was thin.Change
Before opening the page, this test replaces
AbortSignal.timeoutwith a signal that never fires. The test then decides when the held read completes, instead of the runner's speed deciding it. App timeouts aren't what this test covers. The change is test-only and limited to this one test's page.No browser cases added or removed.
Fail-then-pass evidence (local, macOS)
To simulate the slow runner, I temporarily added a 10.5 s wait after the request is held (not committed):
aria-busynever"true"(same failure as CI)Without the wait, the whole
sidebar-unread.spec.mjspasses 28/28 (chromium + webkit,--repeat-each 2).Deferred
🤖 Generated with Claude Code