gatsbyjs/gatsby · critical

${event.data}

Error message

${event.data}

What it means

This is the panic action of the develop state machine (XState). When the state machine transitions to an error state, it dispatches this action, which passes event.data (the error payload from the triggering event) to reporter.panic. The actual message depends entirely on what error event was sent.

Source

Thrown at packages/gatsby/src/state-machines/develop/actions.ts:169

})

export const finishParentSpan = ({ parentSpan }: IBuildContext): void =>
  parentSpan?.finish()

export const saveDbState = (): Promise<void> => saveState()

export const logError: ActionFunction<IBuildContext, AnyEventObject> = (
  _context,
  event
) => {
  reporter.error(event.data)
}

export const panic: ActionFunction<IBuildContext, AnyEventObject> = (
  _context,
  event
) => {
  reporter.panic(event.data)
}

export const panicBecauseOfInfiniteLoop: ActionFunction<
  IBuildContext,
  AnyEventObject
> = () => {
  reporter.panic(
    reporter.stripIndent(`
  Panicking because nodes appear to be being changed every time we run queries. This would cause the site to recompile infinitely.
  Check custom resolvers to see if they are unconditionally creating or mutating nodes on every query.
  This may happen if they create nodes with a field that is different every time, such as a timestamp or unique id.`)
  )
}

export const trackRequestedQueryRun = assign<IBuildContext, AnyEventObject>({
  pendingQueryRuns: (context, { payload }) => {
    const pendingQueryRuns = context.pendingQueryRuns || new Set<string>()
    if (payload?.pagePath) {

View on GitHub (pinned to 8b06340921)

Solutions

  1. Read the full event.data in the output -- it contains the actual root-cause error message and stack.
  2. Address the underlying issue identified by the inner error (webpack error, plugin error, resolver error).
  3. Run `gatsby clean` and restart `gatsby develop`.
  4. If the inner error is from a plugin, update or check that plugin's configuration.
Defensive patterns

Strategy: try-catch

Try / catch

// The state machine panic propagates event.data.
// Guard against errors reaching the panic state by catching in your own actions/services.
exports.onCreatePage = async ({ page, actions }) => {
  try {
    // your logic
  } catch (err) {
    // handle gracefully instead of letting it propagate to state machine panic
    reporter.warn('Page creation issue: ' + err.message)
  }
}

Prevention

When it happens

Trigger: Any error event sent to the develop state machine that transitions to the panic state -- e.g. a webpack compilation failure, a schema rebuild error, or any unhandled error inside a state machine action/service. The event.data field carries the specific Error or message.

Common situations: A webpack error during develop hot reload that the state machine surfaces as a panic. A source plugin error during a query run cycle. A custom resolver or createResolvers hook throwing. The specific message in event.data identifies the root cause.

Related errors


AI-assisted analysis of gatsbyjs/gatsby@8b06340921 (2026-08-13). Data as JSON: /api/errors/252bae3f80e17aa3. Report an issue: GitHub.