New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: Invalid Build File Hash #2978

Closed
adostal opened this Issue Sep 23, 2017 · 12 comments

Comments

5 participants
@adostal
Copy link

adostal commented Sep 23, 2017

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
@tima101

This comment has been minimized.

Copy link

tima101 commented Oct 4, 2017

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.

@adostal

This comment has been minimized.

Copy link

adostal commented Oct 6, 2017

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

@nexdrew

This comment has been minimized.

Copy link

nexdrew commented Dec 12, 2017

@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?

@davscro

This comment has been minimized.

Copy link
Contributor

davscro commented Dec 12, 2017

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",

😉

@nexdrew

This comment has been minimized.

Copy link

nexdrew commented Dec 12, 2017

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

@davscro

This comment has been minimized.

Copy link
Contributor

davscro commented Dec 12, 2017

@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)

@nexdrew

This comment has been minimized.

Copy link

nexdrew commented Dec 12, 2017

@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.

@davscro

This comment has been minimized.

Copy link
Contributor

davscro commented Dec 12, 2017

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

@nexdrew

This comment has been minimized.

Copy link

nexdrew commented Dec 12, 2017

@davscro Good point, maybe a buildId config property?

@nexdrew

This comment has been minimized.

Copy link

nexdrew commented Dec 13, 2017

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"
  }
}
@davscro

This comment has been minimized.

Copy link
Contributor

davscro commented Dec 13, 2017

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

@nexdrew

This comment has been minimized.

Copy link

nexdrew commented Dec 13, 2017

@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.

@lock lock bot locked as resolved and limited conversation to collaborators Dec 13, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.