JavaScript Bundle Issues - Netlify Build Breaking Several Hours after Deployment completes

Support
1

Site ID: bf6e14e2-e3b9-498b-a46b-747fb82ad597

I am experiencing an issue with my website hosted on Netlify, where certain JavaScript files are failing to load. The problem started a few days ago and persists despite local builds working correctly.
Below are the details of the errors encountered:
1764-4b3f4aaf4114ab47.js:1
Failed to load resource: the server responded with a status of 404

yururi/:1 Refused to execute script from ‘https://zendine.co/_next/static/chunks/1764-4b3f4aaf4114ab47.js’ because its MIME type (‘text/html’) is not executable, and strict MIME type checking is enabled.

7116-e77eacb2d0332f49.js:1
Failed to load resource: the server responded with a status of 404

yururi/:1 Refused to execute script from ‘https://zendine.co/_next/static/chunks/7116-e77eacb2d0332f49.js’ because its MIME type (‘text/html’) is not executable, and strict MIME type checking is enabled.

webpack-d006d8ea4672f867.js:1
Failed to load resource: the server responded with a status of 404

yururi/:1 Refused to execute script from ‘https://zendine.co/_next/static/chunks/webpack-d006d8ea4672f867.js’ because its MIME type (‘text/html’) is not executable, and strict MIME type checking is enabled.

page-31e9325dbd67a6cb.js:1
Failed to load resource: the server responded with a status of 404

yururi/:1 Refused to execute script from ‘https://zendine.co/_next/static/chunks/app/[slug]/page-31e9325dbd67a6cb.js’ because its MIME type (‘text/html’) is not executable, and strict MIME type checking is enabled.
It appears that parts of the JavaScript bundle have been discarded after the build, causing these 404 errors. Given that everything works fine locally, I suspect the server might be low on memory or there may be an issue with the deployment process.
Could you please investigate and assist in resolving this issue? If there are any specific logs or additional information required from my end, please let me know.

After clearing the site cache and re-running the build, the errors have been resolved, and the website is functioning correctly for 1 or 2 hours. However, this is not the first time we’ve encountered this issue. We had previously cleared the cache a few days ago, which temporarily resolved the problem. This recurrence leads us to believe that there might be some accumulation happening over time, causing parts of the JavaScript bundle to be discarded.

Given this pattern, we suspect that the root cause might be related to the caching mechanism or server memory limitations. We would appreciate it if you could investigate further to identify any underlying issues that might be causing this accumulation and eventual dropping of JavaScript files.

Is there any specific aspect of our build or deployment process that we should review? Are there any logs or diagnostics we can provide to assist in your investigation?

Thank you for your continued support

2 Likes
2

@zendline You may be encountering this, or something similar:

https://docs.netlify.com/configure-builds/javascript-spas/#code-splitting-or-hashed-filenames

The reason you may see “MIME type” errors is because of your redirects/rewrites.

For example this URL returns HTML:
https://zendine.co/this-url-definitely-does-not-exist.js

This is specifically mentioned in the error:

because its MIME type (‘text/html’) is not executable

So for whatever reason the file doesn’t exist, (it may have existed, but been removed by a subsequent build & deploy), and client side code that knew about it may still make a request for it, resulting in it being given that HTML page instead.

3

Hello,

We have reverted any minor front-end changes we have made this week, and the error is still persisting. The site was previously in a functional state for several months using the same commit hash on the Github repo, leading us to think that it is a problem with server that the site is running on. When the Netlify build runs, the site is functional for a period of time before the issue of white screens starts re-appearing throughout.

4

Update: we have created a second Netlfiy setup using the same Github repo for source code, and it looks like the build is working properly with no MIME issue or missing parts of the JS bundle. So it seems to be a server issue from the original build instance - we suspect it could be the CDN cache, server memory, or some other configuration that needs to be purged or has hit a max limit.

5

@zendine I’d expect everything to always work nicely on a new instance prior to any code changes causing new hashes for files to be generated and old files to be removed.

I presume you’ve tested code changes on the new site instance too?

E.g. Intentionally making changes that cause some of file hashes to no longer exist.

It’s also entirely possible the Next.js stuff works diferently than the standard Netlify handling too, I’ve got absolutely no idea.

7

Hello,

I am experiencing a similar issue on my site since last Thursday. My site also uses Next.js (13.5.6), and according to the deploy log, it appears that Next Runtime v5.5.1 is being used.

In my case, several pages on my site fail to display because .next/_next/static/<random hash>/_buildManifest.js returns a 404 Not Found error almost randomly with each build.

Clearing the cache and rebuilding solves the issue for the previously affected pages, but the problem then occurs on other random pages.

Since I have only made minor changes, I contacted the Netlify support team via email yesterday, assuming it might be a problem on Netlify’s end, but I have not yet received a response.

The more people who confirm this issue, the more likely Netlify will investigate it. If anyone else is experiencing this, please share your experience here.

8

I also spotted this thread earlier which may (or may not) be related:

2 Likes
9

Bumping this thread as it looks like other users are experiencing the same issue. Our production site has been affected for almost 1 week so would like to get this resolved ASAP.

2 Likes
10

FYI this is the second build of the same application on a different instance which appears to be functioning normally unlike our production instance: https://zendine-2.netlify.app

1 Like
11

experiencing the same issue for Next.js app

2 Likes
12

I found that using the Purge API to clear the cache resolves the issue. While the problem may reappear after a few hours, it might be possible to workaround this issue by writing a script that automatically performs a purge approximately every 30 minutes.

13

So the issue is probably stemming from issues with the cache configuration on the server, or cache is filling too quickly and parts of the bundles are getting dropped. But having to manually call the Purge API is just masking the issue, as I might as well host the app on my own server and set up cron jobs to manage my own cache…

14

Our site is over 20,000 pages, and usually the issues start within an hour of running the build, there is no reasonable case where I would need to purge the cache via API multiple times an hour. The other possible scenario is that the site is on a shared server with other Netlify project, and if some other install on the server is littering the cache in some way then all installs on the server are being affected

15

Yes, this is just a workaround. I hope Netlify team fix this issue soon!

In my case, the main issue was not that the static files were actually deleted from the server, but that the cache of HTML containing script tags referencing old file names was continuously returned.

For example, when accessing /foo-page and getting a 404 for xxx.js, the problem wasn’t that xxx.js didn’t exist, but rather that despite the new deployment having the script named yyy.js, the response for /foo-page (HTML) was still returning an old cache referencing xxx.js.

When using Next.js, the script file names include hash values, so the file names easily change if the script content changes. (In my case, it was _buildManifest.js, and since this file was located under a directory name dependent on the Next.js BUILD_ID, the path changed with each build.)

1 Like
16

Just found this thread. Had commented in another thread I found through googling.

I’m encountering same issue:

Screenshot 2024-07-30 at 8.20.34 AM
Screenshot 2024-07-30 at 8.20.34 AM1682×633 126 KB

It certainly has to do with cache not clearing and new files not being cached.

17

@kaw could you provide the name of the site where you’re seeing this behavior?

1 Like
19

@zendine @kaw @ashgrover I’ve escalated this to our developers to take a look at what’s causing this behavior and I’ll continue to update this thread as I hear back.

2 Likes
20

Running into the same issue on our website and we’ve already had our clients complain. Please give us an update if the Netlify team has identified any issues? Started noticing the issue last week.

In our case, the issue occurs on random pages, we’re using “next”: “14.2.4”, and “react”: “^18”. Below you can see the error image of a page with the MIME Issue.

error
error2499×1350 350 KB

Obviously the networks tab shows layout-291085158cbe07e7 not loading

Please any update would be great.

21

I am experiencing the same issue. An error occurs after a certain period. When I test a page, it works fine initially after deployment. However, after 1 or 2 hours, if I refresh the page, an error occurs, and the page stops working. It only works again after I clear the cache and redeploy the site. This process keeps repeating.

I would appreciate any ideas to solve this issue.

FYI, I have another site hosted in a different provider that does not have this issue, even though it has the same structure and files.

Thank you

22

@zendine @kaw @ashgrover @parthNJ @nguyennc94

Thanks so much for your patience here. We’ve opted you out of a feature that we believe was causing this issue. In order to confirm this issue is resolved moving forward, you’ll need to either manually clear the cache and redeploy the site or use the purge API to do so: Caching | Netlify Docs

Please let us know if you have any further concerns or see any issues arise after doing that.

2 Likes