IDDLEWARE_INVOCATION_FAILED — middleware lambda missing @swc/helpers on Next 16.2.4

Feedback
1

Tags: nextjs middleware bug production-down

TL;DR

Production was down for 42 hours starting 2026-05-13 ~22:17 UTC. Every middleware-matched route returned HTTP 500 with x-vercel-error: MIDDLEWARE_INVOCATION_FAILED. Middleware lambda crashed at module-load time with:

Cannot find module '/var/task/node_modules/@swc/helpers/esm/_interop_require_default.js'

Did you forget to add it to "dependencies" in `package.json`?

Node.js process exited with exit status: 1.

The same code, same package.json, same next@16.2.4, same lockfile worked for 8 days before the outage started. Re-promoting older “Ready” deployments produced the same 500 — meaning previously-working immutable lambda artifacts started failing without any user-side change. Posting in case (a) other Next 16.2.x customers are hitting this and (b) it helps Vercel engineering correlate.

Setup

  • Next.js: 16.2.4 (App Router, Node middleware via src/proxy.ts, default Turbopack build)

  • Plan: Hobby (so support escalation was not available)

  • Routing: next-intl with localePrefix: "always"

  • Middleware: src/proxy.ts does Supabase session refresh, auth gating, intl middleware, referral cookie

Timeline

  • 2026-05-05 09:49 UTC — Dependabot bumped next 16.2.3 → 16.2.4. Site worked normally for 8 days after.

  • 2026-05-13 08:48 UTC — Last known-good preview build (PR merge b0ee623).

  • 2026-05-13 ~13:07 UTC — First observed CI failure: wait-for-vercel-preview action got HTTP 500 from a preview build. (Misdiagnosed at the time as a bypass-token issue; was actually this bug already manifesting.)

  • 2026-05-13 22:17 UTC — Production deployment with the bug went live; user-visible outage begins.

  • 2026-05-15 ~22:00 UTC — Recovered via workaround (see below).

So the platform-side change correlation window appears to be 2026-05-13 08:48 to 13:07 UTC.

What did NOT work

I tried five user-level interventions; each was empirically verified by deploying and inspecting Vercel runtime logs:

  1. Add @swc/helpers as direct dependency in package.json (instead of just overrides). No effect.

  2. outputFileTracingIncludes: { '/*': ['node_modules/@swc/helpers/**/*'] } in next.config.ts. Partially worked: regular serverless functions recovered (/favicon.ico went from 500 to clean 404), but the middleware bundle was unaffected.

  3. Static import "@swc/helpers/esm/_interop_require_default.js" inside src/proxy.ts to force a traceable reference. No effect.

  4. Switch prod build from Turbopack to webpack (next build --webpack). No effect — middleware bundle still missing the module.

  5. serverExternalPackages: ['@swc/helpers'] in next.config.ts. (This was Vercel support’s own recommendation.) No effect.

Workaround that recovered the site

Delete src/proxy.ts entirely. No middleware lambda → no MIDDLEWARE_INVOCATION_FAILED. Add a / → /en redirect in next.config.ts redirects() to compensate for next-intl’s localePrefix: "always" 404’ing the bare homepage.

Trade-off: lose Accept-Language locale auto-detection, middleware auth gating, Supabase session auto-refresh, and referral cookie capture, until middleware can be restored. Acceptable triage for a 42h outage; not a real fix.

Asks

  • For Vercel engineering: anything change in middleware lambda packaging / NFT tracing / @swc/helpers handling between 2026-05-13 08:48 UTC and 13:07 UTC for Next 16.2.x projects? Affected deployment IDs (gotosauna project, team saunaenno-9189s-projects):

    • dpl_8JGYAxPQTYZq1HPGGukSPpeeQJoP (broken prod, since 2026-05-13 22:17 UTC)

    • dpl_2SRbWpRi2hWNGZRUvC9VvaNisACC (preview, webpack build, also broken — confirms cross-bundler)

  • For other developers: if you’re hitting this on Next 16.2.x with proxy.ts / middleware on Vercel, the workarounds above did NOT help us; the only thing that recovered the site was deleting the middleware. If you’ve found something better, please share.

Happy to provide more logs or grant temporary access to a Vercel engineer for diagnosis.