[tests] Fix abort-fetch e2e flake#2081
Conversation
…tics
When abortFetchInFlightWorkflow flakes in CI, the assertion failure
("expected 'fetch' to be 'timeout'") gave us no signal as to why
httpbin.org/delay/30 returned early. The step now also reports
`status` and `elapsedMs`, and the test passes the full returnValue
JSON as the assertion message so the next flake reveals the response
status and timing.
Same treatment for abortVoidSleepTimeoutWorkflow which uses the same
step + URL and flakes for the same upstream reason.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 017645f The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
|
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) Stream Benchmarks (includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Next.js (Turbopack) SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
❌ Some benchmark jobs failed:
Check the workflow run for details. |
The diagnostic patch in the previous commit confirmed the abort-fetch flake: httpbin.org/delay/30 returns HTTP 502 from GH Actions runners in 56ms-1709ms intermittently — observed 4 times in a single CI run. Switch the abort-fetch e2e tests to a primary slow endpoint (postman-echo.com/delay/10) with httpbin.org/delay/10 as a fallback that only kicks in when the primary returns a 5xx or non-AbortError network failure. Both upstreams would need to be unhealthy at the same instant to flake the test, which is exponentially less likely than either failing alone. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No backport to This commit fixes flakes in To override, re-run the Backport to stable workflow manually via |
abortFetchInFlightWorkflowwas the most flaky e2e test, with a sibling flake inabortVoidSleepTimeoutWorkflow. Both race a slow fetch against a 2s sleep, and the diagnostic commit in this PR confirmed the root cause:httpbin.org/delay/30returns HTTP 502 from GH Actions runners in 56ms–1709ms intermittently — hit 4 times in a single CI run on the diagnostic commit alone.Two failure modes, both caused by the same 502:
winner='fetch'(fetch wins the race) → first assertion failswinner='timeout'(sleep wins) but the 502 had already resolved, sofetchResult.aborted=false→ later assertions failChanges
Commit 1 — diagnostics.
fetchWithSignalnow reportsstatus,elapsedMs, and per-URLattempts. The two test assertions include the fullreturnValueJSON in their failure messages, so any future flake immediately shows what the upstream returned instead of justexpected 'fetch' to be 'timeout'.Commit 2 — fallback. Switch the slow-endpoint URL from a single
httpbin.org/delay/30to a primarypostman-echo.com/delay/10withhttpbin.org/delay/10as a fallback. The step only calls the fallback when the primary returns a 5xx or non-AbortErrornetwork failure — successful or aborted responses short-circuit. Both upstreams would need to be unhealthy at the same instant to flake the test.The original concern (per-workbench
/api/delayroute) is sidestepped — we stay on shared external services but stop depending on any single one.