Avoid version mismatch between client and server

[sergiodxa]

Scenario

• User access the route /a on v1 of a Remix app.
• The v2 of the Remix app is deployed.
• User clicks a link to route /b.

Here, Remix will try to use the assets for v1 to load the route /b assets. If the assets doesn't exists anymore if fails with a 404.

If the assets still exists (e.g. cached on a CDN) then the Remix app will navigate to the route /b but when it requests the loader of that route it will receive the response returned by v2.

This version mismatch could cause an issue if v1 expected the response to have a specific shape and v2 returned different data (e.g. removed a field from the data).

Idea

Remix has a manifest version, which change on each deploy. If Remix attached an X-Remix-Manifest header with the version to each request, the server-side part of Remix could check if the manifest is the same and continue or detect the change and return a response with a header like X-Remix-Reload: yes, then the client-side part could force a document request by reloading the page.

This should force v2 to be loaded by the browser using the new data, without the using knowing anything about it.

Possible Questions

• What would happen if the request was a Form submit?
• Should the app reload?
• What will happen with the data if the app is reloaded?
• Should the action function run anyway with the old form shape?
• Should there be a way on the action to know there's a version mismatch so we could do something about it?

[kiliman]

Definitely need to figure out a solution for actions. It would really suck if as a user, I create my magnus opus and hit save, and the server just failed and said "Sorry, wrong version" and I lost my masterpiece. 😭

[dmarkow]

I used a similar approach before we migrated to Remix, but it was pretty fragile. We used a combination of websocket notifications and API headers to tell the client there was a new version based on a deploy manifest. We then used a custom Link component that would force a reload on the next link click if there was a new version, but otherwise fall back to react-router's default Link handling. It didn't deal with form submissions at all (no need at the time since we were talking directly to an API rather than using Remix's actions).

I haven't explored adding something like this back in now that we're on Remix, but interested in seeing other approaches. We've been incrementally migrating a pretty large react router app (around 700 routes), and it's been a little painful dealing with stale assets as routes get migrated into Remix. Tech support has been 99% telling users to hard refresh the page.

[davidesigner]

Do you plan to support this use case?

Has anyone implemented custom code to avoid this problem? 🧐

[lukasa1993]

with latest vite-express this cases cause crash or shows fatal error from ErrorBoundary at-least some workaround would be very welcome

[reconbot]

The version drift between clients and servers can get really hairy. This proposal seems great. Though a cookie could be used much the same way.

A straightforward feature might be to have client side fetch() detect the mismatch on navigation and trigger a hard refresh if the response had a different manifest. The server would continue to have a consistent cache friendly response. Clients are therefor responsible for deciding to reload. This would reduce the amount of out of date clients significantly and provide a good user experience at the cost of a single reload for each deploy.

There is no one "solve" for all actions so providing data of the manifest version mismatch on the request would be helpful. A manifest version cookie would be available on the request object in the action. And a method to retrieve the servers manifest version would enable the cookie to be created.

[nickluger]

Vercel already supports version skew detection for Next.js/SvelteKit https://vercel.com/blog/version-skew-protection.

[bbonamin]

I think that this is today solved automatically by remix, which refreshes when it hits a 404 (at least this happens with our ESM vite build). However this is still a problem when changing the shape of the objects returned by actions and loaders :)