@fool I used htop to look at the memory (probably not the perfect way to measure memory but still), and the build process never went above 2GB that I could see.
@hrishikesh I’ve done some more testing, and came to some very interesting findings.
First, I tried building a Gatsby v4 empty project (basically the result of running npx gatsby new), and tried to build it on Netlify and it worked.
This proved there was something in my code breaking things, so I started deleting stuff from my codebase to try to pinpoint what was the offending code, and after a ton of binary search, I found that the problem was with my gatsby-node.js importing a i18n.tsx file. If I deleted that import the build succeeded, so instead I deleted all the code inside that file and did a bunch of tests:
Importing empty file named i18n.tsx → fails
Importing empty file named i18n.ts → fails
Importing empty file named i18n.js → builds
Importing empty file named internationalization.tsx → fails
Importing empty file named internationalization.ts → fails
Importing empty file named internationalization.js → builds
So, at first glance it seems that something (not sure whether Gatsby or Netlify) doesn’t like me importing .ts or .tsx files from inside gastby-node.js… except that I have another import of a .ts file in gastby-node.js and it builds happily anyway, so still not sure what’s the deal here…
If someone from Netlify could take a look at the two builds below and show me the memory usage graph, it might help, as the only difference between them is that one is importing the internationalization.ts empty file and fails, and the other is importing internationalization.js and builds. If this has a large impact on memory usage it might be a Gatsby v4 “problem” with mixing .js and .ts files (or not, I’m far from certain of anything at this point)…
One more thing, the tests above where I only changed the .ts to a .js file, were made with most of my project code deleted.
I now tested picking the whole project, and just changing that file from .tsx to .js, and although the build got a bit further, it still crashed with the exit code 137.
This lead me to believe my theory that importing .ts or .tsx files from .js files is causing the memory spike, but just removing one instance of this in the complete project is not enough, so I went through all my gatsby .js files and converted all .ts imports to .js (and deleted a bit of unused code related with translations) and now my project finally builds!
I’d love to also see the memory usage graph for this build as it has a ton more code than the ones that were failing in my message above. The build id is 63645da494b90500093f09b3.
And just to add that while there is definitely something going on in Gatsby, I’m still convinced there must have been some change in Netlify’s side to trigger this too, because I don’t see any other reason for my Gatsby v4 projects to stop building all at once without any changes in the code.
Hi @hrishikesh, sure, I could try to disable parallel query running to reduce memory, but according to the graphs you shared there seems to be about zero relation between memory usage and whether a build succeeds or fails, which just makes things even more confusing, if possible…
Isn’t there anything else you can do to try to understand why the builds were failing? Because right now I know the solution, but have no idea why it works and what else I could do to prevent this in the future…
Hi @fvieira - The reason my colleague Hrishikesh is mentioning the memory consumption for these builds is that once your build consumes the allocated limit, it will fail. There are builds that can consume a slight bit above the allocated memory and continue without failure, but that is not always a guarantee.
Hi @Kai-Mavyn, sure, I understand that going over the allocated limit should make the build fail, what I don’t understand is that according to those graphs, both the failing and working builds are using the same memory!
I’ve managed to fix the builds by removing most places where I was importing .ts files from my gatsby .js files, but according to the graphs it wasn’t the memory usage that changed… And it’s also not just a random thing, they have been consistently working since I did that change… That’s why I was asking for some help to get to the bottom of why the builds were failing and are now working, since the memory usage doesn’t seem to explain that.
The website is golden-visa-community-website-kw6eskqd, maybe you can check the memory usage for some successful builds and let me know if they are different from the ones killed with code 137.
We’ve checked the memory usage for some of the successful builds for site golden-visa-community-website-kw6eskqd and they do appear to come close to the 8GB memory limit.
The standard build environment that your builds are on is small: we guarantee only 8GB of memory and 4 CPU. When you try to use more memory than allocated your builds will likely abort. This could look like a silent failure as you’ve experienced. But sometimes, you might get lucky and it will just work as our build resources are a guarantee but not a hard limit. Depending on the day/time and how many other builds are processing at the moment, builds that exceed 8GB of memory may sometimes succeed.
Hi @audrey, but do the failing builds (those that failed with the exit code 137) show a different memory usage than the recent succesful ones? Because after my changes, it went from never working to always working, it’s not a “might get lucky” situation.
The situation is:
Gatsby 4 builds for my many projects used to work, no problem
Gatsby 4 builds for all my projects stop working all of sudden in late July without any code changes
Changing a few imports from my gatsby .js files from importing .ts files to importing .js files instead fixes the build permantently
If it was just a case of my projects being close to 8GBs and randomly going above, I wouldn’t see what happened on going from 1. to 2., and when going from 2. to 3., it might have had an impact in memory usage, but then it should be possible to see some difference between the memory usage of successful and failing builds, I think (and the only graphs shared with me doesn’t show this at all).
You may be right on this one! Let us try something here. Can you please lock GATSBY_CPU_COUNT to 1:
if that fails, can you please try to upgrade to our Pro trial (there are no charges on the trial) since that tier offers a different instance to build?
Hi @gualter, I apologize for having gone silent, I didn’t have time to check your last recommendation but I did manage to get my builds working again reliably so I’ll make a post with just my solution so it can be used as a reference.
I’ve finally managed a solution to avoid the exit code 137 error on Gatsby 4 builds.
According to my tests, the problem seemed to be related with mixing imports between .js and .ts files.
But even though I was on Gastby 4, my projects were based on older code where the gatsby files (gatsby-node, gatsby-config, etc.) were still .js files, so my solution was simply to update my projects to use .ts everywhere, so basically converting gatsby files to .ts or .tsx files (and changing imports from requires to ES6 syntax, though that probably had no impact). After this my projects started building fine again.
