"Uncaught SyntaxError: Unexpected token '<'" and/or "ChunkLoadError: Loading chunk 3 failed"

[yarikoptic]

From https://ohbm.sparkle.space/in/home went to https://ohbm.sparkle.space/in/exhibithall (via that modal "Enter" mouse gymnastics excercise) and got blank white screen. looking into console showed

2.915bb609.chunk.js:1 Uncaught SyntaxError: Unexpected token '<'
main.3aefa88f.chunk.js:1 Uncaught SyntaxError: Unexpected token '<'

going back and re-Enter'ing didn't show the issue.

Then clicked Ctrl-Left to go back to Home via browser back, tried to enter https://ohbm.sparkle.space/in/screeningroom -- got the same effect. Going back to Home (Ctrl-Left) took awhile to load (unlike clicking "Back to Home") but finished,... re-Entering still gives the same error. Reloading the page https://ohbm.sparkle.space/in/screeningroom from that white status with Ctrl-Shift-r brings it in.

went around and failed to reproduce again... so not really reliably reproducible but may be smth knowledgeable ppl have a clue about and see how could be addressed.

[0xdevalias]

@yarikoptic This is a sort of 'known issue' that I believe happens when we deploy new code.

It essentially relates to how the webpack'd code bundles are loaded (that's the 'chunk'). I'm not sure of the exact mechanics of this, but I believe it's when the browser still has the /asset-manifest.json file cached (eg. https://ohbm.sparkle.space/asset-manifest.json), yet that manifest is referring to a file that no longer exists on the firebase hosting (that hasn't already been cached locally).

These webpack bundled files include a hash in their filename for caching/cachebusting reasons, so typically they can be left on a CDN for quite a while, older clients can still access them, newer clients will fetch the latest code, and all will 'just work'. I suspect that in our current firebase hosting deployment setup, the old files are being removed straight away each time we deploy, which I suspect means that any clients that are connected when that happens, that have loaded the /asset-manifest.json (but that haven't yet cached all the bundles it refers to) will break with this error.

The simplest 'workaround' is to just refresh the page, and that should load all of the latest code/assets and 'just work' (if a normal reload doesn't work, then a 'hard reload' should).

As far as fixing the issue 'properly', i'm not 100% sure off the top of my head. I expect there are 2 main ways we could look at doing this (possibly a combination of them):

• Ensure that deploying new code to firebase hosting doesn't needlessly remove older assets so that it doesn't break clients that try to reference them
• Ensure that the platform can somehow detect when this sort of error occurs, and suggest a solution to the user (eg. reload the page), or possibly just handle it for them (eg. force a 'hard reload' of a page rather than using 'in-page' React-Router based navigation
• Potentially we could also proactively detect this situation and prompt the client to do something about it, eg. when it detects new code is deployed, suggest that the client reload the page; which is what the firebase admin console seems to do.
  • Not 100% sure on the best method for achieving this, but off the top of my head we could probably re-fetch the /asset-manifest.json on a certain interval, and then compare it to see if it's changed (possibly using e-tags/similar cache methods in the fetch headers?))

[0xdevalias]

I believe the specific Uncaught SyntaxError: Unexpected token '<' part of the error is because we rewrite any URL path (presumably that doesn't match files in public) to /index.html (required to make Single Page Apps (SPA) + React-Router work:

• https://github.com/sparkletown/sparkle/blob/staging/firebase.json#L227-L243

So when the app tries to fetch this chunk that is missing from the hosting, it falls back to trying to load the index.html based on this rule. Since it was expecting JavaScript, but received HTML, it will fail with this error when it tries to parse the received code (since < isn't a valid starter token in JavaScript.

---

Another potential workaround/solution'ish thing here may be to add a new/better rewrite rule that catches these missing JS files and somehow presents a better UI/UX for the user based on that. Not sure if this is any better/even needed once the alternatives in #1570 (comment) are figured out/applied, but capturing it here in case anyway.

[0xdevalias]

Note that a lot of the resources/issues you'll find across the web when searching for this relate to webpack's publicPath setting (and/or how create react app use the homepage field from package.json to set this) (eg. https://www.andreasreiterer.at/fix-whitescreen-static-react-app/), but that is not the source of the issue as we see it here in this project, it's a red herring.

[0xdevalias]

You can read more about Create React App's deployment docs in:

• https://create-react-app.dev/docs/deployment/

And specifically the section on firebase in:

• https://create-react-app.dev/docs/deployment/#firebase

Note that I don't believe we're currently using the service-worker.js file at all (it's disabled I believe), so this note currently doesn't apply:

IMPORTANT: you need to set proper HTTP caching headers for service-worker.js file in firebase.json file or you will not be able to see changes after first deployment (issue facebook/create-react-app#2440). It should be added inside hosting key

[0xdevalias]

Note: You'll also see this error coincide quite regularly with errors like:

ChunkLoadError: Loading chunk 3 failed.
(missing: https://ohbm.sparkle.space/static/js/3.616b5a90.chunk.js)