[Flaky CI]: E2E nextjs-16 Test - [chromium] › tests/server-action-redirect.test.ts:4:5 › Should handle server action redirect without capturing errors

[github-actions]

Flakiness Type

Other / Unknown

Name of Job

E2E nextjs-16 Test

Name of Test

[chromium] › tests/server-action-redirect.test.ts:4:5 › Should handle server action redirect without capturing errors

Link to Test Run

https://github.com/getsentry/sentry-javascript/actions/runs/28363089237/job/84023978407

---

This issue was automatically created.

[linear-code]

JS-2882

[github-actions]

Automated fix attempt — aborting without a PR

I investigated this flaky test (tests/server-action-redirect.test.ts › "Should handle server action redirect without capturing errors") but am not confident enough in a single root cause to open a low-risk PR, so I'm documenting findings instead.

Could not fetch the CI log. The gh api .../actions/jobs/<id>/logs endpoint was not available in this automated environment, so the analysis below is from the test + app code on develop only.

What the test does. It's a negative-assertion test: after a server-action redirect('/redirect/destination'), it asserts that no error is captured within a hard-coded 2-second window. The error listener is created before the click and matches any error in the nextjs-16 project:

const redirectErrorPromise = waitForError('nextjs-16', async errorEvent => {
  return !!errorEvent;
});

Plausible flake mechanisms (could not disambiguate without the log):

1. Transaction timeout — await redirectTransactionPromise (line 29) waits for the GET /redirect/destination server transaction. If that transaction is intermittently slow or named differently under Next.js 16, the whole test times out.
2. Legitimately/intermittently captured error — the SDK is supposed to suppress the internal NEXT_REDIRECT "error" thrown by redirect(). If it is occasionally captured, the test fails. That would be a real SDK regression, not a test flake.
3. Cross-test contamination — the () => !!errorEvent matcher accepts any error from the shared nextjs-16 proxy. An error emitted by another test in the same app, arriving during this window, would fail this test.

Why I'm not opening a PR. Each candidate fix is risky for a negative-assertion test:

• Adjusting the 2s window doesn't help (a longer window only increases the chance of catching a stray error; a shorter one loosens coverage).
• Scoping the error matcher to a specific discriminator could mask mechanism (2) — the exact thing this test guards against — and I cannot confirm the right discriminator without the failing payload.

Recommended next step for a human: pull the failing run's log (run 28363089237, job 84023978407) to confirm whether the failure is a transaction timeout (mechanism 1) or an actually-captured error (mechanism 2/3). The fix differs substantially between those two.

This is an automated analysis; no code was changed.