gatsbyjs/gatsby · error

message?.context?.sourceMessage

Error message

message?.context?.sourceMessage

What it means

When the Gatsby reporter is missing (e.g. running fetch-graphql outside a full Gatsby runtime), gatsby-source-wordpress installs a stub reporter whose panic() rethrows message.context.sourceMessage as a plain Error. So the visible message is whatever upstream code passed as the structured panic payload's sourceMessage. This is a fallback path: in normal builds the real reporter handles the panic instead.

Source

Thrown at packages/gatsby-source-wordpress/src/utils/fetch-graphql.ts:719

  throwGqlErrors = false,
  throwFetchErrors = false,
  url,
  variables = {},
  headers = {},
  errorContext = null,
  isFirstRequest = false,
  forceReportCriticalErrors = false,
}: IFetchGraphQLInput): Promise<IGraphQLDataResponse> => {
  const { helpers, pluginOptions } = getStore().getState().gatsbyApi
  const limit = pluginOptions?.schema?.requestConcurrency

  const { url: pluginOptionsUrl } = pluginOptions
  let { reporter } = helpers

  if (!reporter || typeof reporter === `undefined`) {
    reporter = {
      panic: (message: { id: string; context: { sourceMessage: string } }) => {
        throw new Error(message?.context?.sourceMessage)
      },
      error: console.error as GatsbyReporter["error"],
    } as GatsbyReporter
  }

  if (!url) {
    url = pluginOptionsUrl
  }

  const timeout = pluginOptions.schema.timeout

  const htaccessCredentials = pluginOptions.auth.htaccess

  const missingCredentials =
    !htaccessCredentials.password || !htaccessCredentials.username

  let response: AxiosResponse

View on GitHub (pinned to 8b06340921)

Solutions

1. If you see this in a real build, upgrade gatsby-source-wordpress — helpers.reporter should always be present.
2. In tests, provide a stub reporter with panic/error methods so the real path is exercised.
3. Inspect the panic payload (id and context.sourceMessage) to find which subsystem raised it.
4. Confirm the Gatsby version provides reporter on helpers at the lifecycle being used.

Example fix

null

if (!helpers.reporter || typeof helpers.reporter === 'undefined') { throw new Error('Gatsby reporter missing; running fetch-graphql outside Gatsby?') }

const hasReporter = (h) => h && typeof h.reporter?.panic === 'function'

try { await fetchGraphQL(opts) } catch (e) { if (/context/.test(e.message)) { reporter.error('Stub reporter was used; sourceMessage: ' + e.message) } throw e }

When it happens

Trigger: Calling fetch-graphql in isolation (tests, scripts) where helpers.reporter is undefined; an internal code path that constructs a panic with a malformed context object (missing sourceMessage); a regression where the stub reporter is hit during normal builds.

Common situations: Unit tests for gatsby-source-wordpress that mock the store without a reporter; running pieces of the plugin outside gatsby; a bug causing helpers.reporter to be undefined during a real build.

Related errors

• ${r.errors.join(`, `)}
• createNodeId must be a function, was ${typeof createNodeId}
• createNode must be a function, was ${typeof createNode}
• Neither "cache" or "getCache" was passed. getCache must be f
• GraphQL request returned an empty string.

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