test: deflake trash breadcrumb collapse e2e - #17810
Merged
Merged
Conversation
The "Should collapse breadcrumbs into a popup menu" test set the viewport to 400px, where the expanded breadcrumbs (Dashboard / Posts / Trash / Trashed Post) measure ~298px against ~298px of available space — within 1px. At that knife-edge, StepNav's overflow check (`needed - available > 1`) is a coin-flip, so the toggle sometimes never renders. It failed all retries intermittently on the slower tanstack-start CI variant while passing on next. Dropping the viewport to 320px puts the breadcrumbs unambiguously past the available width (available drops to ~213px vs ~298px needed), making the collapse deterministic. Verified stable across 15 consecutive local runs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
📦 esbuild Bundle Analysis for payloadThis analysis was generated by esbuild-bundle-analyzer. 🤖
Largest pathsThese visualization shows top 20 largest paths in the bundle.Meta file: packages/next/meta_index.json, Out file: esbuild/index.js
Meta file: packages/payload/meta_index.json, Out file: esbuild/index.js
Meta file: packages/payload/meta_shared.json, Out file: esbuild/exports/shared.js
Meta file: packages/richtext-lexical/meta_client.json, Out file: esbuild/exports/client_optimized/index.js
Meta file: packages/ui/meta_client.json, Out file: esbuild/exports/client_optimized/index.js
Meta file: packages/ui/meta_shared.json, Out file: esbuild/exports/shared_optimized/index.js
DetailsNext to the size is how much the size has increased or decreased compared with the base branch of this PR.
|
JessRynkar
approved these changes
Aug 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What / Why
test/trash/e2e.spec.ts→ "Should collapse breadcrumbs into a popup menu when they do not fit the available width" is flaky on thetrash [tanstack-start]CI variant (fails all retries in some runs, passes in others; passes reliably onnext). Seen on PR #17806 and run 31884980215, and confirmed intermittent on recentmainruns too.Root cause
The test used a 400px viewport. At 400px the expanded breadcrumbs (
Dashboard / Posts / Trash / Trashed Post) measure ~298px against ~298px of available space — within 1px.StepNav's overflow check isneeded - available > 1, so at that exact-fit boundary the collapse decision is effectively a coin-flip:Because the
.app-header__step-nav-wrappershrink-wraps to the breadcrumb content, both the collapsed and expanded states are self-stable, so once a run lands "expanded" at the boundary it stays expanded and the toggle never renders. Slower environments (tanstack-start) land on the wrong side of the boundary more often. Reproduced deterministically locally by rendering wide (expanded) then resizing to 400px.Fix
Move the test viewport to 320px (a standard small-mobile width), where the breadcrumbs are unambiguously past the available width (~213px available vs ~298px needed). This makes the collapse deterministic without touching the shared
StepNavcomponent.Verification
-g "breadcrumb"tests in the trash suite pass.Note
The knife-edge is a symptom of a latent measurement quirk in
StepNav:availableis read from a container that shrink-wraps to the breadcrumb content, so the measure is content-dependent rather than a stable available-width reference. That only manifests at an exact-fit width and is benign for users (the breadcrumbs genuinely fit), so it's intentionally out of scope here — flagging for the UI team.🤖 Generated with Claude Code