[Bug] expected expression, got '<'

[sentry-io]

Sentry Issue: APPSMITH-G5

UnhandledRejection: Non-Error promise rejection captured with keys: code, message, show

[Nikhil-Nandagopal]

This is a really bad experience @mohanarpit @riodeuno @hetunandu
We kept thinking it was a safe error but if you see the smartlook, the user sees a blank screen and is just confused about what to do
https://app.smartlook.com/org/9b6c5c859e85745d01196fa4/project/e373e3a21d27278fd281d8b0/recordings?playSession=Ggs8t-d9Ph&playVisitor=pCLpcXMMxp

[github-actions]

This issue has not seen activity for a while. It will be closed in 7 days unless further activity is detected.

[github-actions]

This issue has not seen activity for a while. It will be closed in 7 days unless further activity is detected.

[riodeuno]

@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.

[hiteshjoshi]

@sharat87, the current finding suggests that this happens when the server is down and js files are not being served at all.

[sharat87]

@riodeuno, thanks for the detailed write-up. So, if the service worker got a 404 response from the server, instead of the HTML, will it realize its mistake and update the JS filename? With the new hash? If yes, I can get NGINX to return 404 here, without affecting the rest of the functionality.

Edit, for completeness, if the answer to the above question is yes, the we'll add the below block to our NGINX configuration and this issue will be resolved.

  location ~ \.js$ {
    try_files \$uri =404;
  }

[hetunandu]

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

[hetunandu]

This issue can only be verified over time by checking if the trend here goes down

https://sentry.io/organizations/appsmith/discover/results/?display=default&field=title&field=release&field=environment&field=user.display&field=timestamp&name=%3Cunknown%3E&project=1546547&query=issue.id%3A2129275999&sort=-timestamp&statsPeriod=90d&yAxis=count%28%29

We can look back at this after a couple of version releases

[kocharrahul7]

Seems to still be present

[rohan-arthur]

looks like its come back @kocharrahul7 @hetunandu
https://appsmith.sentry.io/discover/results/?display=default&field=title&field=release&field=environment&field=user.display&field=timestamp&name=%3Cunknown%3E&project=1546547&query=issue.id%3A2129275999&sort=-timestamp&statsPeriod=90d&yAxis=count%28%29

[hetunandu]

New sentry errors are unrelated to this issue

[ohansFavour]

The new sentry errors will be fixed in #27519