What causes "Context is not available" in honojs/hono?

Ensure app.use(contextStorage()) is applied before any handler that uses getContext()

honojs/hono · error · Error

Context is not available

Error message

Context is not available

What it means

This error is thrown by getContext() from hono/context-storage when called outside the AsyncLocalStorage context established by the contextStorage() middleware. The middleware stores the request Context in an AsyncLocalStorage; getContext() retrieves it and throws if the store is empty because no request scope is active. tryGetContext() is the non-throwing variant that returns undefined instead.

Source

Thrown at src/middleware/context-storage/index.ts:56

 * const getMessage = () => {
 *   return getContext<Env>().var.message
 * }
 * ```
 */
export const contextStorage = (): MiddlewareHandler => {
  return async function contextStorage(c, next) {
    await asyncLocalStorage.run(c, next)
  }
}

export const tryGetContext = <E extends Env = Env>(): Context<E> | undefined => {
  return asyncLocalStorage.getStore() as Context<E> | undefined
}

export const getContext = <E extends Env = Env>(): Context<E> => {
  const context = tryGetContext<E>()
  if (!context) {
    throw new Error('Context is not available')
  }
  return context
}

View on GitHub (pinned to e2740d5a1b)

Solutions

Ensure app.use(contextStorage()) is applied before any handler that uses getContext()
Move logic that needs the Context inside the request flow, or pass the Context/values explicitly to async callbacks
Use tryGetContext() and handle undefined when the call site may be outside a request
In tests, wrap calls in a request through the app (or the storage run) rather than calling helpers directly

Example fix

// before
const getUser = () => {
  const c = getContext() // throws in cron job
  return c.get('user')
}

// after
const getUser = () => {
  const c = tryGetContext()
  return c?.get('user') // undefined outside a request
}

Defensive patterns

Strategy: type-guard

Validate before calling

import { tryGetContext } from 'hono/context-storage'
const maybeCtx = tryGetContext()
if (!maybeCtx) {
  // outside a request: use explicit arguments instead
}

Type guard

import { tryGetContext, type Env } from 'hono/context-storage'
const inRequestScope = (): boolean => tryGetContext() !== undefined
const getContextSafe = <E extends Env = Env>() => {
  const c = tryGetContext<E>()
  if (!c) throw new Error('Context is not available')
  return c
}

Try / catch

try {
  const c = getContext()
} catch (err) {
  if (err instanceof Error && err.message === 'Context is not available') {
    // fallback: pass values explicitly
  }
}

Prevention

Always register contextStorage() middleware before handlers that use getContext()
Prefer tryGetContext() in any code that might run outside a request
Pass Context explicitly into setTimeout/queue/event callbacks instead of relying on ALS
In tests, invoke helpers through app.request() so the storage is populated

When it happens

Trigger: Calling getContext() in code reached outside a request (module init, scheduled job, CLI startup, WebSocket disconnect handler after the request completed); calling it inside a callback that escaped the async chain (e.g. setTimeout/setInterval not awaited within the request, event emitter handlers registered earlier); forgetting to register app.use(contextStorage()) before the code runs.

Common situations: Background tasks kicked off during a request that outlive it, queue consumers sharing code with request handlers, forgetting the contextStorage middleware in tests, or calling getContext in a top-level await during bootstrap.

Related errors

AI-assisted analysis of honojs/hono@e2740d5a1b (2026-08-28). Data as JSON: /api/errors/b7c3ad447893cbf5. Report an issue: GitHub.