The build process completes successfully locally, but ot hangs at the very last step when building on Netlify. Here is the tail end of the build log (complete log here):
8:01:49 PM: success onPostBootstrap - 0.248s
8:01:49 PM: ⠀
8:01:49 PM: info bootstrap finished - 9.290s
8:01:49 PM: ⠀
8:01:50 PM: success run static queries - 0.936s - 11/11 11.76/s
8:02:14 PM: success Building production JavaScript and CSS bundles - 24.712s
8:02:15 PM: success Rewriting compilation hashes - 0.002s
8:02:15 PM: success run page queries - 0.768s - 143/143 186.14/s
8:02:21 PM: success Building static HTML for pages - 5.884s - 143/143 24.30/s
8:02:21 PM: Algolia: 6 queries to index
8:02:21 PM: Algolia: query #1: executing query
8:02:22 PM: Algolia: query #2: executing query
8:02:22 PM: Algolia: query 1: graphql resulted in 3 records
8:02:22 PM: Algolia: query 1: splitting in 1 jobs
8:02:22 PM: Algolia: query #3: executing query
8:02:22 PM: Algolia: query 2: graphql resulted in 7 records
8:02:22 PM: Algolia: query 2: splitting in 1 jobs
8:02:22 PM: Algolia: query #5: executing query
8:02:22 PM: Algolia: query 4: graphql resulted in 8 records
8:02:22 PM: Algolia: query 4: splitting in 1 jobs
8:02:22 PM: Algolia: query #6: executing query
8:02:22 PM: Algolia: query 5: graphql resulted in 5 records
8:02:22 PM: Algolia: query 5: splitting in 1 jobs
8:02:22 PM: Algolia: query #4: executing query
8:02:22 PM: Algolia: query 3: graphql resulted in 9 records
8:02:22 PM: Algolia: query 3: splitting in 1 jobs
8:02:22 PM: Algolia: query 0: graphql resulted in 95 records
8:02:22 PM: Algolia: query 0: splitting in 1 jobs
8:02:27 PM: Algolia: query 5: moving copied index to main index
8:02:27 PM: Algolia: query 2: moving copied index to main index
8:02:27 PM: Algolia: query 1: moving copied index to main index
8:02:27 PM: Algolia: query 3: moving copied index to main index
8:02:27 PM: Algolia: query 0: moving copied index to main index
The build stops there and never finishes–successfully or with an error. The build takes about two minutes locally, so I’d expect a comparable time here, so I stop it after a while–ten minutes or so–because I’m afraid to use up my build allotment.
Hoya @mbwatson and sorry to be slow to get back to you! It’s odd for the logs to cut off right there and I have opened a bug report on it, but I’d guess the reason for the failure is an out of memory error. As far as I can tell the build process has terminated right after logging the deletion lines, with no other activity on our side (except the system eventually noticing that things went off the rails, and cancelling the deploy).
Could you speak to the memory usage of that plugin on your local system? I’m hoping for something like “without the plugin I can run in 2Gb, but with it my usage is more like 6Gb peak” if you have tools that can give that observability. I haven’t heard of anyone else having trouble with that plugin, but that doesn’t mean it isn’t a problem on the same scale as the image handling plugins (cf 5 Optimizations to Get Faster Gatsby Builds Today).
Thanks for your response! A memory issue does indeed seem like a good place to start. Would you mind pointing me toward a tool that will provide these insights to finished processes so that I can compare? I’m running Ubuntu 18.04.
I should also have noted that for my local builds, the output does show the onPostBuild and index to Algolia messages, so presumably it gets to that same point on Netlify as well. The output is animated and thus doesn’t show in the log viewer in “Deploy Details” in Netlify, but here is a screenshot from a local build:
Hi, @mbwatson. To me this looks a lot like a build that isn’t returning control to the build system because of some process that is still running in the background.
We have a support guide about this type of issue here:
The fact it is happening after the Algolia queries also strengthens the hypothesis that this is related to a subprocess or unclosed network connection of some kind.
Regarding finding memory issues, Gatsby is a node app so looking for node memory profiling techniques would be a good place to start.
That being said, personally, I think this looks like the Angolia subprocess doesn’t return (or close the connection handler) and not a memory issue. If it were me, I would start by looking for a connection close issue first.
