"Uncaught SyntaxError: Unexpected token <" on new build using gatsby JS

[addoolaghe]

I’m experiencing some issues with an error that has already been mentioned in this post :

[Support Guide] Why do I see “Uncaught SyntaxError: Unexpected token <” errors? How can I use chunking or versioning for my assets at Netlify?

Last reviewed by Netlify Support on December 2022 The error Uncaught SyntaxError: Unexpected token < is most commonly caused by your site’s code referring to an asset that is no longer available. Most commonly, this is due to a filename change in assets generated during your build. The same situation happens if you use versioned or chunked javascript where the filename changes with every deploy. Let’s look at an example: A file that was named /assets/main-123abc.js would change to /assets…

The site is build with GatsbyJS.

The Netlify URL is working well and I cannot reproduce the issue.

Nooz Optics | Blue Light glasses I Sunglasses I Reading glasses

My primary domain is producing the error on certain url for exemple.
https://www.nooz-optics.com/us/en-us/

Some screenshot of the error logs in browser console:

The mentioned post suggests two solutions:

• disabling those hashes (which I don’t think is an option with GatsbyJS)
• service workers (which is disabled on this site)

I unsure how to resolve this caching issue. I have re-deployed with cache cleared many times. The issue appears every time I re-deploy some change on the site.

It would be grateful to have some help on this.

FYI, we are using Cloudfare for the DNS redirection (The CDN proxy has been disabled)

[fool]

Pretty sure this post is what you need:

[Support Guide] Why do I see “Uncaught SyntaxError: Unexpected token <” errors? How can I use chunking or versioning for my assets at Netlify?

Last reviewed by Netlify Support on December 2022 The error Uncaught SyntaxError: Unexpected token < is most commonly caused by your site’s code referring to an asset that is no longer available. Most commonly, this is due to a filename change in assets generated during your build. The same situation happens if you use versioned or chunked javascript where the filename changes with every deploy. Let’s look at an example: A file that was named /assets/main-123abc.js would change to /assets…

Let us know if not!

[addoolaghe]

Hey @fool,

Thanks for your response, I had indeed looked at this post.

Following both suggestion in the article, I have temporarily remove the service worker on the application. But I can still reproduce intermittently the issue from there. The issue is not reproducible consistently.

When I download the build application on Netlify, I cannot see any issues and the files are all in place.

However I’m curious about some 301 redirects from disk cache that fails to give a valide response type. See below on the screenshot of the Gatsby webpack runtime js file requst.

Failing exemple (“Nooz Optics | Reading glasses | Blue Light glasses I Sunglasses”)

Successful exemple (“Nooz Optics | Reading glasses | Sunglasses | Blue Light glasses”)

Are this type of 301 redirects from disk cache usual behaviours ? The response is a “Text/Plain” instead of script file.

I also cannot reproduce this behaviour using the preview netlify url of the same build… Which makes me believe this is not related the built application itself ?

Let me know you can think of something to help on this !
Thanks in advance!

[addoolaghe]

The issue behaviour are exactly the same as described Missing assets - 301 status code

@johnedvard mentioned “We managed to use CI, with automated builds from bitbucket (instead of dragging our dist folder into Netlify), and the the same problem has not occurred (yet). Maybe Netlify is doing something important when they build the application instead of us.”

However I am currently unable to use netlify CI due to specific env variable setup to build the application. I am building the application locally, then pushing the entire app. (something I would like to improve in the future).

Can you confirm if using drag and drop might cause the issue I’m experiencing ?

[perry]

hi there, thanks for that. We are talking internally about this still - we haven’t forgotten about you! We’re not quite sure yet what is causing this issue.

[addoolaghe]

Thanks @perry for coming back to me on this.

FYI I had to added as a temporary fix a “no-cache” tag in the headers of all my request. The issue was affecting the production site. The “no-cache” tag removed the issue. This is obviously not ideal and would need to be removed soon.

Let me know if you need more information about the issue raised.

[Dennis]

Hi, it looks like you cross posted on another thread. It does look to be the same issue. I’ve posted a response on that thread but wanted to circle back here so anyone looking at this thread knows where to look.

[harlandomain]

Any update on this?

I’m a little confused why more people aren’t running into this issue. I have a gatsby site and I see this error being logged in Sentry every time I do a deploy, mostly from iOS users on the latest version. Is the plugin gatsby-plugin-remove-serviceworker causing the issue? If so, I could remove it, but my site doesn’t have any functionality that will work offline so I don’t see the need for the service worker.

And in the case that there is nothing I’m doing explicitly wrong, what is the best workaround right now?

Will adding the offline plugin back and the following code to gatsby-browser.js fix things?

export const onServiceWorkerUpdateReady = () => {
    window.location.reload();
}

[fool]

This post describes the reasons for the problem in more detail:

[Support Guide] Why do I see “Uncaught SyntaxError: Unexpected token <” errors? How can I use chunking or versioning for my assets at Netlify?

Last reviewed by Netlify Support on December 2022 The error Uncaught SyntaxError: Unexpected token < is most commonly caused by your site’s code referring to an asset that is no longer available. Most commonly, this is due to a filename change in assets generated during your build. The same situation happens if you use versioned or chunked javascript where the filename changes with every deploy. Let’s look at an example: A file that was named /assets/main-123abc.js would change to /assets…

It also has our best suggestions on working around it:

• ensure that you don’t use asset fingerprinted filenames wherever possible (this plugin may help: gatsby-plugin-remove-fingerprints | Gatsby) but also make sure that the netlify-plugin-gatsby isn’t setting your cache timeouts ridiculously, which it tends to do, assuming that the filenames will change with every deploy!)
• or have a client-side handler that notices such failures and forces a hard refresh to pick up a new “referring” page that will have references that are correct to filenames that may have changed due to you deploying that change, between the initial pageload and the followup click.

Removing your service worker is also a good idea to help with this, but it won’t address the root cause of “a page loaded into a browser before a deploy won’t find files you removed in a later deploy when it tries”.