[✨] Reload page when QRLs return a 404 after code has changed and been redeployed

[DustinJSilk]

Is your feature request related to a problem?

When a production codebase is updated, the urls to QRL can change. This means that the website breaks for all users that are currently on the website.

Requests to fetch each chunk abort with a 404.

This can be tested by running a preview server, changing the code and restarting it, then interacting with the website.

Describe the solution you'd like

Since QRLs are serialised into the html, my guess is that we would need to completely refresh the page to update them.
Unless there is a mechanism to refetch them.

It might be better to have an event/hook so that developers can decide what to do next when this happens.

Describe alternatives you've considered

We can't create aliases at build time because a user might have already loaded an out-of-date script which is incompatible with a newer version of another script.

This also didnt catch the aborted requests:

useOnWindow('error', () => {})

Additional context

This causes major issues with continuous integration.

[gioboa]

Hi @DustinJSilk, with the latest version of Qwik, is it still a valid issue?

[DustinJSilk]

Hi @gioboa, I havent tested it, is there a commit that has addressed the issue?

[gioboa]

In my production app I saw a refresh because of that.
Now I'm trying to reproduce the case without success.

[gioboa]

This PR #5521 solves the issue. Thanks @DustinJSilk for reporting it.

[DustinJSilk]

@gioboa this still exists for me. The browser can still get stuck having the JS files cached and returning 404s until the site data is cleared and the page is refreshed. No amount of refreshing helps until the cache is emptied.

Can we please reopen this the website can get completely bricked by this issue.

This was tested on v1.4.5 which was released after that code change. i will monitor this with v1.5.3 going forward as well.

[wmertens]

That PR isn't sufficient, it's only for navigation, not for any other js loading.

[wmertens]

Note that 1.5.3 supports skew protection on vercel, which is another way of solving this, by making sure clients talk with a server that has their version.

Only works for 12 hours though, unless you pay more.

So the reload is still necessary.

[DustinJSilk]

Thanks for giving this your time, @wmertens !!

It seems like there are 2 issues at play here:

• The docs state: Each build will create a new service worker, and the old service worker will be automatically unregistered. So if the page is refreshed and there is a new app, the service worker should get replaced and there shouldnt be any outdated code running. This didn't work for some reason until the user cleared all site data in the dev tools.
• The other issue is when the app gets updated after the page has already loaded and then the QRLs start returning 404s or failing due to updates to the server side code.

Could we achieve something similar to Vercel Skew Protection (Im not on vercel unfortunately)

• In some middleware we set a cookie with a site version, if a request arrives with an old version, we return a redirect to a page that can do a refresh. This should reregister the SW and clear the cache. Though as mentioned above it seems like there might have been another bug causing it to not work.

It doesn't seem very elegant and Im not sure if theres a better Qwik way of doing this.

[PatrickJS]

@DustinJSilk if you're using aws or anything with s3 to host the files you can deploy everything in /build folder in the same /build folder. this will fix the preview/next file version issue for files. For routeAction$ you can pass id string value as a second object to map to the same routeAction$ even when version changes. I'll add id config to server$ and see if we can add something in the framework for others to figure out the skew versions.

for vercel you have a deployment-id in a cookie then for each request you just map the deployment-id to the correct location. because its a cookie this will also attach to any assets but I mention above the fix is just deploying everything in /build in the same folder on a cdn since everything in /build is immutable

if the app was pwa then the version of the app will be downloaded (but still have mismatch action/loader/server$)
https://github.com/QwikDev/pwa