Generating JavaScript bundles failed - app.js from Terser

Hi there, I’m running out of ideas here :slight_smile:

I’m able to build on my local machine and with netlify-cli. That’s good. I’ve moved my account from Pro to Business in the hope that the build could then take advantage of some more resources during the deploy. Yet I’m hitting this error:

Deploy log

12:44:13 AM: success onPreInit - 79.088s
12:44:13 AM: info One or more of your plugins have changed since the last time you ran Gatsby. As
12:44:14 AM: a precaution, we're deleting your site's cache to ensure there's no stale data.
success initialize cache - 0.078s
12:44:14 AM: success copy gatsby files - 0.084s
12:44:14 AM: success onPreBootstrap - 0.020s
12:44:15 AM: success createSchemaCustomization - 0.014s
12:45:33 AM: success Checking for changed pages - 0.001s
12:45:33 AM: success source and transform nodes - 78.417s
12:45:39 AM: success building schema - 6.063s
12:47:45 AM: info Total nodes: 15640, SitePage nodes: 5816 (use --verbose for breakdown)
12:47:45 AM: success createPages - 125.829s
12:47:45 AM: success Checking for changed pages - 0.001s
12:47:45 AM: success createPagesStatefully - 0.172s
12:47:45 AM: success Cleaning up stale page-data - 0.071s
12:47:45 AM: success update schema - 0.017s
12:47:45 AM: success onPreExtractQueries - 0.001s
12:47:46 AM: success extract queries from components - 0.730s
12:47:46 AM: success write out redirect data - 0.002s
12:47:47 AM: success Build manifest and related icons - 0.290s
12:47:47 AM: success onPostBootstrap - 0.292s
12:47:47 AM: info bootstrap finished - 309.571s
12:48:04 AM: success run static queries - 17.324s - 5/5 0.29/s
12:48:16 AM: success run page queries - 11.673s - 5823/5823 498.84/s
12:48:16 AM: success write out requires - 0.083s
12:50:27 AM: failed Building production JavaScript and CSS bundles - 131.653s
12:50:27 AM: error Generating JavaScript bundles failed
12:50:27 AM: app.js from Terser
12:50:27 AM: Error: Call retries were exceeded
12:50:27 AM:     at ChildProcessWorker.initialize (/opt/build/repo/node_modules/terser-webpack-plugin/node_modules/jest-worker/build/workers/ChildProcessWorker.js:191:21)
12:50:27 AM:     at ChildProcessWorker._onExit (/opt/build/repo/node_modules/terser-webpack-plugin/node_modules/jest-worker/build/workers/ChildProcessWorker.js:268:12)
12:50:27 AM:     at ChildProcess.emit (events.js:315:20)
12:50:27 AM:     at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12)
12:50:28 AM: npm ERR! code ELIFECYCLE
12:50:28 AM: npm ERR! errno 1

As for the Gatsby version I’m on version 2.30.x, Node version 14.15.0

Can anyone suggest what I could be looking out for in order to successfully deploy this build? I’ve refactored some of the logic related to node creation and the page queries given the amount of nodes and pages I’ve started to be dealing with. I’d believe that’s improved and it’s not the reason of the failure as nodes and queries gets passed with success.

hi @LuigiClaudio ! i don’t have an answer for you, just checking to see if you knew you can reach out to the helpdesk with a business level account where you might get faster help? Although the forums are pretty speedy these days…

1 Like

So, I took a look at this since Perry pointed out that you’d get quicker help in the helpdesk and wanted to try to unblock you before the weekend!

The Business level accounts don’t have any more build resources than the Pro (or free) account levels, so let me know if you’d like my help downgrading and getting a refund for that since it wouldn’t help.

I see you say the build does work locally which is a great start! Some suggestions to make sure our build is the same as yours are in this article: [Support Guide] Debugging Netlify site builds (for instance: I see you say you’re on the same node version that we use in that build - but what about yarn?)

I also see that you have a yarn.lock - so we install your modules using yarn:

…but then you run your build with npm. Is there a reason for this? It’s not usual to mix the two…if you want us to install with npm instead of yarn you can either remove yarn.lock from your repo or set $NETLIFY_USE_YARN to false as described here: Manage build dependencies | Netlify Docs

Another trick that you can use to try to understand more about the nature of the failure (this is not one I’ve seen before and I’ve debugged over 10,000 builds in the past 4 years), would be to show the npm debug log. Since the filename changes every time, and we want to make sure your bad deploy doesn’t get published, we have to get a bit tricky to show it!

This pattern should work:

assume your normal build command is npm run build (I know, yours is about 8 commands, but I’m not sharing them here, the advice will remain the same). To show the error file AND still fail the deploy, this is the change you’d make:

append this to it:

; cat /opt/buildhome/.npm/_logs/*-debug.log ; sleep 100 ; false

that will show the log, give our system time to save it, and then fail the deploy. Hopefully the info in there is helpful to you in resolving the root cause!

1 Like

Thank you so much for the message. How would I get in touch with the helpdesk?

Thank you so much, really appreciate the speedy effort in helping out with suggestions.

Yes, you’re absolutely correct, I’ve replaced the build command with yarn and made sure it uses the same version I use on the local machine where the build completes with no issues. Good catch, it was an oversight and since it always worked, it didn’t catch my attention.
I’ve addressed that but still the build fails. I carried on looking into a possible root cause, I’m at the stage in which I believe that one of the pages has such a large data context that there’s a some sort of Out of memory failure but silent that gives me back now a generic:

10:14:46 PM: warning The size of at least one page context chunk exceeded 500kb, which could lead to degraded performance. Consider putting less data in the page context.
10:15:09 PM: error Command failed with exit code 1

These builds succeed instead where I make sure that the possible pages with a larger context are not part of the built:

I’ve come across this dance that Gatsby does when it comes to handling the redux data

  writeFileSync(reduxSharedFile(targetDir), v8.serialize(contents))

and I’ve started to wonder whether the writeFileSync method used here is what triggers the possible OOM issue. It’s just a thought as I’m new to this and I’ve only recently find out and refactored a solution in this very same project that was using readFileSync in favor now of createReadStream in order to avoid OOM issues for larger in memory data handling.

As for printing the log files, thank you that’s great to know and I wasn’t aware of it. However since I now use yarn for running the build, I couldn’t find the location of the yarn logs. I tried my luck with this path but no joy:
cat: '/opt/buildhome/.yarn/_logs/*-debug.log': No such file or directory - any chance you could help with this?

I’ve started the same discussion on the Gatsby repo in the hope of getting some suggestions there as well:

hi @fool, is there anyone looking into this or I should use the helpdesk and leave this thread here?

hi @LuigiClaudio, i think you might get faster help in the helpdesk! Please email from the email associated with the paid account and we will get back to you as soon as we can.

1 Like