Devflare Docs
Runtime internals Devflare

How Devflare establishes runtime context

This page keeps the AsyncLocalStorage mechanics out of the normal usage guide while preserving them for maintainers and advanced debugging.

Use this page when helpers work in one runtime lane but not another, when you are changing runtime infrastructure, or when you need to verify exactly what Devflare stores while a handler is active.

Audience
Maintainers and advanced runtime debugging
Normal app page
Core primitive

What Devflare stores while a handler is active

Devflare creates and stores more than the current request. The context includes environment bindings, execution context or Durable Object state, optional request, mutable locals, runtime surface type, and the original event object.

That is why the higher-level runtime APIs can stay small. Per-surface getters return the stored event when the active surface matches, and the runtime proxies read the same context without forcing every helper to receive the event manually.

The original event object is preserved

Devflare does not discard the richer surface event after extracting a request or context. The original event stays on , which is what the per-surface getters read later.

Simplified shape of the stored runtime context

How Devflare creates and installs the context

For fetch, queue, scheduled, email, tail, and Durable Object surfaces, Devflare first creates a rich event object using helpers such as , , or the Durable Object event builders. It then builds a from that event and runs the handler trail inside .

The same mechanism is reused by generated worker entrypoints, request-wide middleware, route resolution, Durable Object wrappers, the dev server, and helpers such as , , , , and .

  1. 1

    Devflare builds the rich event object for the active surface.

  2. 2

    It creates a from , , , , , and the original event object.

  3. 3

    It runs middleware, route resolution, or the surface handler inside with that context.

  4. 4

    Helpers call getters or proxies, which read the current store instead of receiving the event manually.

  5. 5

    When the handler trail ends, strict runtime helpers stop exposing context.

The important part of `runWithEventContext()` is intentionally small

and are infrastructure helpers

By the time you are considering these helpers, the normal app-facing story should already be working: handlers, middleware, generated entrypoints, and establish context for you. These APIs exist for runtime and test infrastructure that must preserve or synthesize that context deliberately.

preserves an existing rich event object. is the lower-level compatibility helper: it creates fresh locals, synthesizes a default event with , and then stores that event before running your function.

Do not reach for the escape hatch by habit

If you are writing app code instead of runtime or test infrastructure, pass the event into your handler and let Devflare establish the context automatically.

Wrap one infrastructure assertion with an existing event

Previous

Runtime context

Use explicit event parameters at handler boundaries, then use , , , , , , and inside helper code that runs during the same request or job.

Next

sequence(...)

Use from when broad HTTP concerns must wrap route resolution or another fetch handler in a clear top-to-bottom order.