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
- Read the full event.data in the output -- it contains the actual root-cause error message and stack.
- Address the underlying issue identified by the inner error (webpack error, plugin error, resolver error).
- Run `gatsby clean` and restart `gatsby develop`.
- 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
- Catch errors in your own gatsby-node.js and plugin code so they don't reach the state machine panic.
- Read event.data in the panic output to find the root cause.
- Keep plugins updated.
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
- Missing compiler
- A recipe must be specified
- for custom ssl --https, --cert-file, and --key-file must be
- You're trying to generate a ssl certificate for an IP (${ssl
- Missing required params
AI-assisted analysis of gatsbyjs/gatsby@8b06340921 (2026-08-13).
Data as JSON: /api/errors/252bae3f80e17aa3.
Report an issue: GitHub.