fix(e2e): widen move_toast BeforeAll Eventually timeouts (residual flake) (bookshelf-49zk3) #1330
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "bd-bookshelf-49zk3"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
The
journey_move_toastBeforeAll drives a real async bulk-move workflow through SSE/poll to toast resolution. Per-stepEventuallytimeouts of 10–15s were occasionally too short under CI CPU contention, causing the test to time out at steps like "click organize toolbar button" and "Move Files button should appear" (#1324, #1328).Root cause: per-step budgets were sized for an uncontended runner. Under CPU starvation, CDP round-trips and Stimulus controller DOM updates take materially longer than the generous median.
Fix: widen every per-step
Eventuallytimeout in the BeforeAll:Also bump the BeforeAll page deadline from 3min → 5min to accommodate the new summed worst-case (~330s). All assertions and polling intervals are unchanged — only the wait windows are wider. The
refreshPageTimeout(page)call before each step (added by b8p9v) remains in place.Test plan
go build -tags e2e ./e2e/browser/...compiles cleanCloses bead bookshelf-49zk3 on merge.
Security Review — PR #1330 (bookshelf-49zk3)
Scope:
e2e/browser/journey_move_toast_test.go— browser e2e flake fix; swaps blockingpage.Element()calls for non-blockingpage.Elements()insideEventuallyloops and widens per-step timeouts.Build gate:
//go:build e2e— this file is compiled only when-tags e2eis supplied. It is entirely absent from the production binary and from unit/integration test runs. No production code is touched.Package:
package browser_test— correct black-box test declaration.Security surface analysis
setAuthCookies(existing helper, not modified). No gate removed or weakened.booksURLis built from a server-controlledsuiteEnv.BaseURLand a seededsrcLibID. No new outbound fetch.style=change.Elements()[0]is functionally equivalent toElement()for presence checks. Timeouts are widened (more retries), not shortened — this cannot mask a real failure.No security finding of any severity. The change is a pure wait-mechanic fix: replacing a blocking single-element fetch with a non-blocking multi-element fetch so the
Eventuallyretry loop can actually iterate within its budget, plus widening budgets to match observed worst-case CI latency. Nothing in the security checklist applies.REVIEW VERDICT: 0 blocker, 0 major, 0 minor
Code Review: bookshelf-49zk3 / PR #1330
Scope:
e2e/browser/journey_move_toast_test.goonly — test-only flake fix.Phase 1: Spec Compliance
The bead targets the root cause of the
journey_move_toastbrowser flake:page.Element()(singular) internally blocks up topageTimeout(60s) when an element is absent, making the surroundingEventuallyloop meaningless — the first attempt burns the entire window before Gomega can retry. The fix replaces everypage.Element()call insideEventuallywithpage.Elements()(plural, non-blocking), and widens budgets to give retries real room.All requirements verified present:
page.Element()inside anEventuallyblock has been replaced withpage.Elements()— nopage.Element()remains in the file.len(els) > 0/len(els) == 0) is present on every converted call.[0]indexing only occurs after the length check — no index-out-of-range path exists.Orderedjourney container,package browser_test(black-box), no per-specResetDB.Phase 2: Code Quality
[MINOR] e2e/browser/journey_move_toast_test.go:109 — BeforeAll comment overstates worst-case sum by 90s
The comment claims the "sequential Eventually budgets sum to ~330s worst-case" but the actual sum is 60+60+45+45+45+45+45+45 = 390s. The 5-minute outer deadline (300s) is not violated in practice because
refreshPageTimeoutissuesCancelTimeout().Timeout(60s)before each step, so each step runs within a fresh 60s window and the outer deadline only governs the pre-first-refresh setup block (setAuthCookies + incognito creation). The comment's arithmetic is simply wrong and will confuse the next reader. Suggested fix: update the comment to reflect that the 5min deadline guards the pre-refresh preamble, and that each step resets to a fresh 60s window, so the sequential sum does not compound against the outer deadline.[MINOR] e2e/browser/journey_move_toast_test.go:243 — error-toast It has zero margin between page timeout and Eventually budget
BeforeEachcallsrefreshPageTimeout(issues a fresh 60spage.Timeout). The error-toastItthen runsEventually(..., 60*time.Second, 500ms).page.Elements()is non-blocking so the page context is not blocked per-call, but if any single call hits a slow CDP round-trip, the 60s page context and the 60s Gomega window expire simultaneously — the page context can cancel the CDP call at the same instant Gomega declares timeout, producing a context-deadline error whose message will be confusing. A 5s margin (e.g. 55s Eventually or 70s page context via a localrefreshPageTimeoutat the top of thatIt) eliminates the edge case. Not a correctness bug on healthy runners; a rare-race under extreme starvation.No blockers. No majors.
REVIEW VERDICT: 0 blocker, 0 major, 2 minor
2d2e20074bf470a79ff5