State and logging

HTTP requests carry identifiers and optional log context that middleware and handlers share through the framework logger. This page connects request state to Logging.

requestId on every request

Each FlareRequest has a requestId assigned by the framework. When request-id headers are enabled in host config, the same value is sent as X-Request-Id.

Use it in handlers:

host.http.get("/trace", (ctx) => {
  return new FlareResponse(200, { requestId: ctx.req.requestId });
});

Error handlers receive context.requestId on HttpErrorContext (not ctx.state).

enableContext

When log.enableContext is true in resolved config, log records from the same request share an async-local context frame. Middleware and handlers that resolve Logger (via this.inject(Logger) or an inject map entry) see consistent context fields on each record.

{
  "log": {
    "enableContext": true
  }
}

Or: FLARE__LOG__ENABLECONTEXT=true.

See Logging and flare.json reference.

withLogging on state tokens

flareState().withLogging(mapper) merges mapper output into the logger’s async-local store after each set (including values from derivation or defaults):

import { flareState } from "@flare-ts/core";

const AuthUser = flareState<{ id: string }>("AuthUser").withLogging((user) => ({
  userId: user.id,
}));

Requires an active logger ALS frame (enableContext: true on supported runtimes). Without it, the mapper is skipped safely.

Other surfaces

WebSocket connections carry a connectionId in their log context instead of an HTTP requestId; see WebSockets. For log context inside Cloudflare Durable Objects, see Durable Objects. Both require log.enableContext.

Related

• Declaring state: withLogging helper
• Preserve log context on Workers