Question
Astro middleware pipeline with Cloudflare Workers edge runtime concurrency
Nia Cedar
0 reputation · 09 Oct 2026, 17:52 UTC
20.7K views
Loading…
0 reputation · 09 Oct 2026, 17:52 UTC
Astro middleware runs on every SSR or hybrid request before page rendering and API routes. When deployed with an edge adapter such as Cloudflare Workers, Vercel Edge Functions or Netlify Edge Functions, the middleware executes inside the runtime's isolate model.
The pipeline is serial by design, with each middleware awaiting next(). Under concurrent requests the interaction between serial per-request execution and isolate concurrency is not documented. It is unclear whether module-level state in a middleware file is shared across concurrent requests in the same isolate, and how edge runtime CPU time limits interact with a chain of middleware under burst load.
What guarantees exist for request isolation of middleware execution in Astro on edge runtimes? Is global state in middleware files safe under concurrent requests, or must all state be confined to context.locals? How should middleware latency be reasoned about when multiple requests are processed concurrently in the same isolate?
34775 reputation · 09 Oct 2026, 20:34 UTC
Astro middleware executes serially for each SSR or hybrid request. The only guaranteed, request-scoped mechanism for passing data between middleware, endpoints, and templates is context.locals. All request-specific state (e.g., authenticated user, request ID) must be confined here.
Module-level state (mutable variables defined outside the middleware function) is not guaranteed to be isolated across concurrent requests when using Cloudflare Workers. Since Workers reuses isolates for efficiency, mutable module globals risk being shared and corrupted across simultaneous requests.
astrocontext.locals.Middleware latency is additive and serial within a single request. Under burst load, concurrent requests compete for the isolate's CPU budget; long middleware chains increase the risk of hitting per-invocation CPU or duration limits enforced by the Cloudflare plan.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 10 Oct 2026, 04:31 UTC
On Cloudflare Workers, a single V8 isolate handles multiple concurrent requests on one thread. Module-scope variables in your middleware file (e.g., let cache = new Map()) persist for the isolate lifetime and are visible across all requests processed by that isolate. Only context.locals, request-scoped variables, Durable Objects, or KV provide request isolation.
This means a middleware that mutates a module-level counter or cache will exhibit cross-request contamination. The Astro Cloudflare adapter composes the entire middleware chain into one fetch handler, so the Workers runtime semantics apply directly: single-threaded event loop, shared module scope, per-request CPU accounting.
Under burst load, CPU-bound middleware (heavy parsing, crypto) blocks the isolate and delays all concurrent requests until it yields. Async I/O (fetch, KV reads) yields the event loop, allowing interleaving. Tail latency grows not just from your own chain's CPU time but from queuing behind other requests' CPU work in the same isolate.