11904

11904

Error message

Expected compiled files not found after compilation for ${siteRoot} after ${retries} retries.\nFile expected to be valid: ${compiledFileLocation}${sourceFileLocation ? `\nCompiled from: ${sourceFileLocation}` : ``}\n\nPlease run "gatsby clean" and try again. If the issue persists, please open an issue with a reproduction at https://gatsby.dev/new-issue for more help.

What it means

Thrown when the Parcel bundling worker fails to produce Gatsby-file bundles and all `RETRY_COUNT` (5) retry attempts are exhausted. The code runs Parcel in a worker to survive segfaults; on failure it clears Parcel's cache and retries with exponential backoff. If the error carries `diagnostics` it is handled as a normal compile error, otherwise after the final retry a panic is raised with siteRoot, retry count, and the underlying error message. The user is pointed to `gatsby clean`.

Source

Thrown at packages/gatsby/src/utils/parcel/compile-gatsby-files.ts:159

    await emptyDir(distDir)

    await exponentialBackoff(retry)

    let bundles: RunParcelReturn = []
    try {
      // sometimes parcel segfaults which is not something we can recover from, so we run parcel
      // in child process and IF it fails we try to delete parcel's cache (this seems to "fix" the problem
      // causing segfaults?) and retry few times
      // not ideal, but having gatsby segfaulting is really frustrating and common remedy is to clean
      // entire .cache for users, which is not ideal either especially when we can just delete parcel's cache
      // and to recover automatically
      bundles = await worker.single.runParcel(siteRoot)
    } catch (error) {
      if (error.diagnostics) {
        handleErrors(error.diagnostics)
        return
      } else if (retry >= RETRY_COUNT) {
        reporter.panic({
          id: `11904`,
          error,
          context: {
            siteRoot,
            retries: RETRY_COUNT,
            sourceMessage: error.message,
          },
        })
      } else {
        await exponentialBackoff(retry)
        try {
          await remove(getCacheDir(siteRoot))
        } catch {
          // in windows we might get "EBUSY" errors if LMDB failed to close, so this try/catch is
          // to prevent EBUSY errors from potentially hiding real import errors
        }
        await compileGatsbyFiles(siteRoot, retry + 1)
        return

View on GitHub (pinned to 8b06340921)

Solutions

Run `gatsby clean` to wipe `.cache` and `public`, then retry.
Free memory / close other heavy processes; if in CI, increase the node memory limit (`NODE_OPTIONS=--max-old-space-size=4096`).
Ensure only one Gatsby process is running against the project dir.
Update Gatsby and Parcel-related deps to match the Gatsby major (node engine `>= 18.0.0` for major 5).
If reproducible, capture the underlying error message and report at https://gatsby.dev/new-issue with a reproduction.

Defensive patterns

Strategy: retry

Validate before calling

// Cheap preflight before building: ensure single-process and enough memory.
function preflightCompile(siteRoot) {
  const used = process.memoryUsage().heapTotal / 1024 / 1024
  if (used > process.env.NODE_OPTIONS_MAX_OLD_SPACE || false) {
    return `Heap already near limit before compile; raise --max-old-space-size.`
  }
  return null
}

Try / catch

// Gatsby already retries 5x internally; wrap a higher-level clean+retry once.
async function buildWithClean(siteRoot, run) {
  try { return await run() }
  catch (e) {
    if (/11904/.test(e?.message ?? String(e))) {
      await require('fs-extra').remove(`${siteRoot}/.cache`)
      return await run()
    }
    throw e
  }
}

Prevention

Run `gatsby clean` after upgrades before the first build.
Ensure no second Gatsby process holds `.cache/.parcel-cache`.
Set NODE_OPTIONS=--max-old-space-size=4096 on large sites.
Keep Gatsby CLI and gatsby package on the same major.

When it happens

Trigger: `worker.single.runParcel(siteRoot)` throws an exception without a `diagnostics` property on the 5th (final) retry. Typically a native segfault inside Parcel/worker, an out-of-memory kill, a corrupt Parcel cache that clearing did not fix, or a Parcel internal error unrelated to source diagnostics.

Common situations: Running out of memory during develop/build on large sites; flaky native parcel cache after an interrupted run; Node/Parcel version skew after a Gatsby upgrade; concurrent Gatsby processes fighting over `.cache/.parcel-cache`; antivirus/FS watcher interfering with the worker.

Related errors

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