mirror of
https://github.com/cloudflare/vinext.git
synced 2026-05-09 08:25:34 +02:00
[GH-ISSUE #901] Flaky E2E: rsc-fetch-errors.spec.ts "redirect chain to a non-ok endpoint hard-navs to the post-redirect URL" #199
Labels
No labels
enhancement
enhancement
good first issue
help wanted
nextjs-tracking
nextjs-tracking
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vinext#199
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Originally created by @NathanDrake2406 on GitHub (Apr 25, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/901
Symptom
tests/e2e/app-router/rsc-fetch-errors.spec.ts:156(redirect chain to a non-ok endpoint hard-navs to the post-redirect URL) times out onpage.waitForURL("/about", { timeout: 10_000 })and fails both initial run andRetry #1. PR #900 isn't touching app-router code, so the failure is unrelated to the diff under test.Failing run: https://github.com/cloudflare/vinext/actions/runs/24939159481/job/73029827222?pr=900
Reproduction signal
Playwright trace shows the main frame navigated to
/redirect-srcthree times in a row, never advancing to/about:The test's intercept chain depends on Playwright re-dispatching the route table on the 307 follow-up so both the
/redirect-src.rsc(307 →/about.rsc) and the/about.rsc(500) handlers fire in sequence. The author already flagged this fragility intests/e2e/app-router/rsc-fetch-errors.spec.ts:168-172:The CI failure looks like exactly this scenario inverted: Playwright followed the 307 to
/about.rscitself without re-dispatching the route, so the 500 handler never fired and the navigation guard kept retrying the original/redirect-srcrequest.Hypotheses
route.fulfill307 follow behaviour to internal-follow (no re-dispatch). Worth pinning the Playwright version and re-running the suite.page.goto("/"), hydration, and the intercept registration; if the intercept is replaced by the second registration before the first fetch lands, the 307 chain breaks. Less likely givenpage.routeregisters synchronously.Locationheader pointing at/about.rsc, but the request URL has a query string in some runs ((\?|$)regex match), which can desync the second intercept on the bare path.Suggested fix direction
Replace the dual-intercept-and-pray pattern with an explicit redirect-follow strategy: a single
page.routematcher that distinguishes the two URLs by inspectingrequest.url(), then returns 307 or 500 deterministically without depending on Playwright's route-redispatch semantics. Alternatively, route through a real test server that issues the 307 and 500 directly so the browser follows the chain without test-side mocking.Severity
Blocks CI on unrelated PRs (e.g. #900). Should be quarantined or re-skipped until the redirect-chain mocking is reworked.
@james-elicx commented on GitHub (Apr 27, 2026):
I don't believe this was fixed was it?