Next.js: Error: Invalid Build File Hash

Created on 24 Sep 2017  路  12Comments  路  Source: vercel/next.js

I find issue#2294 of this repository, but I can't repair this bug.

I use Google Cloud AppEngine with multiple instances.
First I change BUILD_ID (compile with typescript to dist directory), this is OK:
"create-build-id": "node -e \"process.stdout.write(require('./package.json').version)\" > dist/.next/BUILD_ID;"

No success.

I try repair with Handle-BUILD_ID-Mismatch-Error

No success.

Error is in only Next.js 3.x in version 2.x is everything okay.

Error stack trace:
Error: Invalid Build File Hash(330ff6344cd3331927cdad0f77db8688) for chunk: app.js at Server.handleBuildHash (/app/node_modules/next/dist/server/index.js:1249) at Server._callee9$ (/app/node_modules/next/dist/server/index.js:475) at tryCatch (/app/node_modules/regenerator-runtime/runtime.js:65) at Generator.invoke (/app/node_modules/regenerator-runtime/runtime.js:303)

Environment

| Tech | Version |
|---------|---------|
| next | 3.x |
| node | 8.x |
| OS | linux |
| browser | all |
| etc | Google Cloud AppEngine |

Most helpful comment

In the meantime, I created this little CLI package, in case it helps other folks too: https://www.npmjs.com/package/next-build-id

With this package, it's as simple as doing this in package.json:

{
  "scripts": {
    "build": "next build && next-build-id"
  }
}

All 12 comments

I had the same issue with running instance (deployed on zeit).
Instance was running fine for days, then crashed with error on logs:

Error: Invalid Build File Hash(13b6f9096e8b79e637b7d43d02c97d73) for chunk: app.js
...

Then after some time, server ran npm start by itself, and app got restarted, currently runs without error.

Next 3.0.6

Update:
I've used this solution higher-order component:
https://github.com/zeit/next.js/wiki/Handle-BUILD_ID-Mismatch-Error
Will monitor logs. I don't have problem for now.

I found solution.
You can modify build-stats.json (hash) in .next directory (after build).

For example, I use this script in package.json:
"create-hash": "echo {\\\"app.js\\\":{\\\"hash\\\":\\\"xxxx\\\"}} > dist/.next/build-stats.json",
"prestart": "npm run build && npm run create-hash",

This solution works on Next 3.x and 4.x

@timneutkens What would you think about a PR that adds a CLI flag to next build that lets folks optionally override the hash/uuid contents of build-stats.json/BUILD_ID with, say, the result of git rev-parse HEAD? Maybe something like next build --git-id or even just next build --id=xyz. Do you think the Zeit team would be open to that?

You can always use something like:

   "build": "npm run build1 && echo $(git rev-parse HEAD) > .next/BUILD_ID && echo {\\\"app.js\\\":{\\\"hash\\\":\\\"$(git rev-parse HEAD)\\\"}} > .next/build-stats.json",
    "build1": "rimraf .next && NODE_ENV=production next build",

:wink:

@davscro Cool, thanks, but that's kinda ugly and brittle IMO. 馃槂 Would be nice if there was a more official solution.

@nexdrew I agree with you it's a little bit hacky/ugly but In my opinion it's the same as your proposal because anyway you have to provide some logic for random build_id (in this case last git commit hash)

@davscro If the solution was included as a part of Next.js, then it would be easier to guard against regression if more requirements are added in the future (e.g. if the file/format of BUILD_ID ever changes or if something changes about the way hashes are stored in build-stats.json). In other words, the solution would no longer be a hack since we could write tests to guarantee compatibility with the official Next.js codebase.

@nexdrew yes, you're right. Then I whould say next.config.js is right place to override default behaviour 馃槈

@davscro Good point, maybe a buildId config property?

In the meantime, I created this little CLI package, in case it helps other folks too: https://www.npmjs.com/package/next-build-id

With this package, it's as simple as doing this in package.json:

{
  "scripts": {
    "build": "next build && next-build-id"
  }
}

Cool, thanks for the package, will try it instead of my local setup.

@davscro Sure thing, thanks for taking a look. It works in my setup, but please let me know if you have any suggestions for improvement.

Was this page helpful?
0 / 5 - 0 ratings