gatsbyjs/gatsby · critical
11903
11903
Error message
There was an unhandled error during compilation for ${siteRoot}. Please run the command with the --verbose flag again.\n${sourceMessage} What it means
Thrown by the top-level catch around the entire compile loop when an unexpected (non-diagnostic) error escapes. If the error has a `diagnostics` array it is forwarded to `handleErrors`; otherwise the error is wrapped in a panic with siteRoot and the raw `error.message`, advising `--verbose`. This is the catch-all for failures that are neither structured Parcel diagnostics nor the bundle-validation retry path.
Source
Thrown at packages/gatsby/src/utils/parcel/compile-gatsby-files.ts:239
}
await compileGatsbyFiles(siteRoot, retry + 1)
return
}
const mainEntry = bundle.mainEntryPath
// mainEntry won't exist for shared chunks
if (mainEntry) {
if (mainEntry.endsWith(`.ts`)) {
compiledTSFilesCount = compiledTSFilesCount + 1
}
}
}
} catch (error) {
if (error.diagnostics) {
handleErrors(error.diagnostics)
} else {
reporter.panic({
id: `11903`,
error,
context: {
siteRoot,
sourceMessage: error.message,
},
})
}
}
}
function handleErrors(diagnostics: Array<Diagnostic>): void {
diagnostics.forEach(err => {
if (err.codeFrames) {
err.codeFrames.forEach(c => {
// Assuming that codeHighlights only ever has one entry in the array. Local tests only ever showed one
const codeHighlightsMessage = c?.codeHighlights[0]?.message
// If both messages are the same don't print the specific, otherwise they would be duplicateView on GitHub (pinned to 8b06340921)
Solutions
- Re-run with `gatsby develop --verbose` (or `gatsby build --verbose`) to surface the full error stack.
- `gatsby clean`, then `rm -rf node_modules && npm install` (or yarn/pnpm equivalent) to rule out a corrupt install.
- Align Gatsby CLI and `gatsby` package versions (`gatsby --version` vs package.json).
- Read the `sourceMessage` in the panic and address the underlying cause (fs error, native module, etc.).
- Open a reproduction at https://gatsby.dev/new-issue if no cause is identifiable.
Defensive patterns
Strategy: try-catch
Type guard
function isParcelDiagnosticArray(error) {
return error != null && Array.isArray(error.diagnostics)
} Try / catch
// Mirror Gatsby's own branch: route diagnostics to user-friendly handling,
// surface everything else with full verbosity.
try {
await compileGatsbyFiles(siteRoot)
} catch (error) {
if (isParcelDiagnosticArray(error)) {
handleErrors(error.diagnostics)
} else {
console.error('[compile] unexpected:', error)
process.exit(1)
}
} Prevention
- Always have `--verbose` available in your build scripts to surface the sourceMessage.
- Pin Gatsby CLI and gatsby package to the same version to avoid Parcel API drift.
- Reinstall node_modules after switching Node major versions.
When it happens
Trigger: Any exception during the compile loop that does not expose a `diagnostics` property — e.g. a thrown string, a Node fs error, a TypeError inside Parcel plumbing, or a worker IPC failure. Reached when the error is not recognized as a compile diagnostic and not caught by the bundle-validation inner try/catch.
Common situations: Gatsby/Parcel version mismatch after a partial upgrade; native module load failure; corrupted node_modules; unexpected Parcel API change; transient OS errors during bundling.
Related errors
AI-assisted analysis of gatsbyjs/gatsby@8b06340921 (2026-08-13).
Data as JSON: /api/errors/7f5a973e152bc68f.
Report an issue: GitHub.