What causes "\n\n\t${sharedError}\n\tSee above for more information." in gatsbyjs/gatsby?

Read the console.error(e) output above the panic: it prints the original thrown error and stack, which identifies the failing step name and line.

gatsbyjs/gatsby · critical

112003

112003

Error message

\n\n\t${sharedError}\n\tSee above for more information.

What it means

Thrown by gatsby-source-wordpress run-steps when any step function (a source plugin build step, e.g. a node sourcing routine) throws an uncaught error during the named step. It wraps the error as code 112003 (SourcePluginCodeError), invokes leftover preview callbacks to report to WP Preview, logs the original error to stderr, and panics. It signals a bug or unhandled runtime error inside the plugin's own step code rather than in user configuration.

Source

Thrown at packages/gatsby-source-wordpress/src/utils/run-steps.ts:63

      }

      if (activity) {
        activity.end()
      }
    } catch (e) {
      const sharedError = `Encountered a critical error when running the ${
        apiName ? `${apiName}.` : ``
      }${step.name} build step.`

      // on errors, invoke any preview callbacks to send news of this error back to the WP Preview window.
      await invokeAndCleanupLeftoverPreviewCallbacks({
        status: `GATSBY_PREVIEW_PROCESS_ERROR`,
        context: sharedError,
        error: e,
      })

      console.error(e)
      helpers.reporter.panic({
        id: CODES.SourcePluginCodeError,
        context: {
          sourceMessage: formatLogMessage(
            `\n\n\t${sharedError}\n\tSee above for more information.`,
            { useVerboseStyle: true }
          ),
        },
      })
    }
  }
}

/**
 * Takes in a pipe delimited string of Gatsby Node API names and returns the first supported API name as a string
 *
 * Example input: "onPluginInit|unstable_onPluginInit"
 * Example output: "onPluginInit"
 */

View on GitHub (pinned to 8b06340921)

Solutions

Read the console.error(e) output above the panic: it prints the original thrown error and stack, which identifies the failing step name and line.
Pin gatsby-source-wordpress to the version that worked, then upgrade WPGraphQL and the plugin together.
Re-run schema introspection / clear the .cache directory (rm -rf .cache node_modules/.cache) so stale type info is rebuilt.
If a custom step is failing, wrap its body in a try/catch and return a recoverable result, or remove it from the step list.

Defensive patterns

Strategy: try-catch

Try / catch

// Inside your custom step, catch and surface rather than letting run-steps panic:
try {
  await myStep(helpers)
} catch (e) {
  helpers.reporter.warn(`myStep failed, skipping: ${e.message}`)
  // optionally re-throw only for fatal cases
}

Prevention

Keep gatsby-source-wordpress and WPGraphQL versions in lockstep.
Clear .cache after schema changes on the WP side.
Wrap custom step functions in try/catch to log context before the plugin's panic runs.
Reproduce failing steps against the live WPGraphQL endpoint to isolate the cause.

When it happens

Trigger: A step in the source plugin's step list throws synchronously or rejects asynchronously; the try/catch in run-steps catches it and calls reporter.panic. Common when the plugin's internal helpers receive unexpected shapes from WPGraphQL (schema drift), or a third-party step is misconfigured.

Common situations: Updating gatsby-source-wordpress to a version incompatible with the installed WPGraphQL schema; custom step functions added via sourceNodes step arrays; race conditions in preview-state cleanup; node type definitions missing after a WP schema change.

Related errors

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