@hiteshjoshi @arunvjn Yes, this happens when the browser requests .js and we get an HTML response.

How does this happen?

nginx automatically serves index.html or a 404.html, when the resource requested isn’t available.

Which scenario do I think causes this?

Say, we are trying to fetch asset.somehash.js (mentioned in the deployment1’s index.html) which has for some reason either

1. expired in the service workers cache,
2. the service worker is using the precacheAndRoute (similar to the cache first) strategy and there is a cache miss, or
3. it was never cached so far and is freshly being requested from the servers or 4. service worker registration has failed and it falls back to network only.

In this while, there is a deployment2 which has happened, resulting in the actual asset being asset.somenewHash.js while asset.somehash.js no longer being available on the servers. Nginx now returns the contents of index.html or some 404.html file in response. The browser fails to parse this as JS and we see the error.

I suspect the cause is 4.

After some debugging, we noticed that #8324 was not kicking in because the right events were not getting triggered when the user comes back to a tab after some time @sharat87 @riodeuno and I have come to the decision that adding another event on our RTS server and client to check for user tab visibility will solve this problem by showing the “New version available” toast to the user at the correct time

Seems to still be present