Hello Vercel community,
Our production domain returns 504 MIDDLEWARE_INVOCATION_TIMEOUT intermittently. Four times in 90 minutes yesterday, with normal successful requests in between. Next.js 14.2.35, Edge middleware, Hobby plan.
What makes this strange: the dashboard reports "External APIs: No outgoing requests" for the failing invocation. The middleware ran for 25.2s without issuing a single network call, at 212 MB of 2048 MB. So there is nothing in our code to await, and nothing to put a timeout on.
The middleware has exactly one potential network call, supabase.auth.getUser() from /ssr. With no session cookie it short-circuits in the library and issues no request, which matches what the dashboard shows. middleware.ts hasn't changed in 37 days, package-lock.json in 57, and the build uses npm ci, so dependencies are identical between the last two builds. Our own backend answered 200 in 0.2s during the incident. Cloudflare is DNS-only. Vercel status was green.
Vercel's support agent suggested an unresolved promise or an unreleased lock inside
/ssr. We checked the installed package: _initialize() is gated behind
isBrowser() and does nothing server-side, and the server lock is lockNoOp
(lib/locks.js:31-33), whose entire body is return await fn(). Neither can wait.
We also found GLOBAL_JWKS in auth-js, a module-level mutable cache whose own docstring mentions shared-memory environments like Vercel. It looked like a perfect fit for warm isolate reuse. It isn't: its only writer is fetchJwk, whose only caller is getClaims(), and we call getUser(), never getClaims().
So we're out of leads on our side. Has anyone seen an Edge middleware hang for the full 25s with no subrequests? Anything that would stall an isolate without touching the network is what we're after.
Request IDs, if a Vercel engineer reads this: cdg1::4hmws-1787912158766-72ce01b76571 cdg1::hgz4k-1787912256761-ac27888bf915 cdg1::ck7kc-1787912889247-a5d03c62883d cdg1::g45dq-1787917391939-5c26423128f0 Deployment: dpl_GLeEP4tyKoEvCNsFyt8QDam6armn