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

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

The site is build with GatsbyJS.

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

My primary domain is producing the error on certain url for exemple.

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)

Pretty sure this post is what you need:

Let us know if not!

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.com/ca/en-ca”)

Successful exemple (“nooz-optics.com/eu/en-eu”)

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!

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 ?

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.

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.

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.

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 = () => {
1 Like

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

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: https://www.gatsbyjs.com/plugins/gatsby-plugin-remove-fingerprints/) 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”.