upgrade of full stack causes failures due to mismatched frontend/backend versions

[brianmay]

I am finding that when the deployed version has been updated, the server function endpoints change and the client starts generating errors (it is still trying to access the old end points which are somehow hashed). This requires force reloading the client (e.g. shift click the reload button in Firefox IIRC). IIRC just clicking reload doesn't work.

Because everything is in the client, we are not downloading html pages with the correct references. And in any case it looks like the wasm is linked to directly without any hashing in the filename:

<link rel="preload" href="/./wasm/penguin_nurse_bg.wasm" as="fetch" type="application/wasm" crossorigin="">
<link rel="preload" href="/./wasm/penguin_nurse.js" as="script">

Which is OK for me, not OK if I want to deploy websites that others will use.

Is there any better way of handling this?

I don't think there is anything I missed in the docs on this, but I might have missed something.

Unfortunately, I don't think I can use Dioxus full stack for anything serious while this problem remains.

Originally posted by @brianmay in #3496

[ealmloff]

This looks like the same issue as #3350 which will be fixed by #3531

[brianmay]

Wonder if hashing the filenames is actually going to be sufficient here.

Problem is that the hashed filename is referenced in the index.html file. And the client is not necessarily going to load a new copy of the index.html file (unless something triggers it to do so like clicking the reload button) so it won't get the new hash.

[ealmloff]

Wonder if hashing the filenames is actually going to be sufficient here.

Problem is that the hashed filename is referenced in the index.html file. And the client is not necessarily going to load a new copy of the index.html file (unless something triggers it to do so like clicking the reload button) so it won't get the new hash.

The index.html caching policy needs to be much more restrictive since we don't hash that name. Every time the page is loaded the browser needs to check it has the most recent version of the index.html file. If another asset changes, that should change the links in the index.html file and cause a refetch for the assets that change. Then every time the page is reloaded even if it isn't a hard reload, it should have the most recent version of all assets

For sessions that are when a new build is pushed it could be a good idea to serve the old version of assets for a while to make sure all sessions end and get the new index.html with the links to the new assets. This should be as simple as serving the old and new assets at the same time. Since the hash is based on the contents of each file, the old and new files should not conflict if they have different content. We don't have support for this in dx today, but it would be a good feature to add in the future

[brianmay]

Keeping old assets might make builds more complicated, you need to have the old assets to build the new. Unless the deploy just copies assets to an asset folder somewhere that is regularly cleaned up.

More importantly though, this isn't going to help with server functions, which is where I am getting the errors. I have a copy of the wasm running on my phone, and do an upgrade of the server.

The phone continues running the old wasm without even considering trying to update the index.html file, and will try to make requests like http://localhost:4000/api/get_users11843745895277440839.

(am curious how this path is generated)

But this path is no longer valid for the server function. Instead it will point now to my Not Found handler (presumably; not tested) which will generate errors when the Not Found handler doesn't generate the expected json result.

I can't think of any good solutions though really. About the best I can think of is some sort of /get_version end point (not a server function that is hashed), and have the client regularly check that the version matches and if it doesn't then tell the user to reload. Or something like that.

Presumably, if you change the caching policy on index.html and have it point to a hashed filename for wasm, just a simple reload should be sufficient, no need for a forced reload (shift-click).

[ealmloff]

The wasm assets are now hashed from #3531 which I believe fixes the original issue? When the page is reloaded, the browser should fetch the new index.html and find the latest version of the wasm which will only reference the latest version of the server functions.

For desktop/mobile apps you could keep running the old version of the server functions for a while after an update. Eventually, the desktop/mobile client will need to be updated. You could use an unhashed server function endpoint to differentiate between the server/network being down and the old apis no longer being served. The hash should also be somewhat more stable now than it was when this issue was originally opened. It is now based on the module path instead of the byte location of the macro

Alternatively, if you want to opt-out of hashed endpoints for server functions you can use #[server(endpoint = "/yourpath")] which will not change as you update the server. You will still need to handle changes in your API over time if the format of your request/response changes

[brianmay]

As above "when the page is reloaded" is the key here.

The problem is though that the user could still have the page open from before the upgrade, and then there is nothing to trigger the reload. And the page will come up with random errors which are probably meaningless to the non-programmer.

Running the old version of the server functions would help, but no idea how you would actually do that... My experience is that the hashes change even though the functions have not changed (not sure how they are generated). I think I saw this recently (but didn't investigate in detail).

In any case, this needs to be better documented.

[ealmloff]

The hash that server functions add make the issue more frequent, but version skews are an issue you will need to deal with in any system with a frontend and API. Server functions are very conservative with versioning by default and change the hash if they notice any potentially breaking change. If you prefer, you can manually version your api by setting #[server(endpoint = "/v1/your_fn")]. This lets you maintain more backwards compatible apis with manual versions. You will still run into some version skews when you update the version.

You can handle the version skew in a couple different ways:

• Automatically reload or prompt the user to reload the page if the server function returns an error from a missing api
• Maintain a sliding window of old versions of server functions by running multiple older versions of your server as a fallback. This is the approach vercel/nextjs uses, but it could be difficult if your server maintains internal state which would need to match between multiple server binaries. The simplest way I can think of to set this up in the current system is to keep around old server binaries and pass requests that reach the fallback route to the previous server version if the current server version does not recognize the api request

[brianmay]

An example to demonstrate these might be good.

If you specify endpoint, does this mean the function is not automatically hashed anymore?

This does look attractive, typically my function signatures don't change that often. And if it does, you can support both old and new endpoints in the one executable.

But of course, fun and games if it does change and I forget to deal with it :-)