dApp - force reload update short circuit service worker

[weilbith]

Description

According to my comment here (includes link to W3C specification) a force-reload of the light client can lead to serious issues. Quickly rephrasing, a force-reload will bypass the service worker and loads the assets directly from the server. This means the user is getting the most recent version available on the server, no matter which version was running before. The user probably does not recognize this in first place. There is no notification about an update or anything else. Anyway, as soon as the user closes the tab where he force-reloaded the client and then load the client later again, it will load the former "old" version again as usual. This is because our service worker will always serve the locally available version if the user does not manually trigger the update. Though the force-reload short circuit the service worker and its cache storage, it will keep the cache intact (which the "old" version). In result the user was using the new version for a temporally time frame.

There can be a couple of serious issues because of that. Two obvious ones are the contracts version and the database version. For the first case, the user will load a new version of the client that is linked to a new version of contracts. He will be confused because his old channels are not there anymore. But maybe he doesn't even recognize this and just blindly follows the quick pay or similar. Anyway, when he returns to the old version he also gets back his old channels. This leads to a lot of confusion and frustration, spending unnecessary many for gas costs etc.
The second issue is about the database scheme version of the SDK to persist the client data. New versions of the client can include a new version of the database scheme. The SDK will automatically migrate the old data to the new scheme. But if the user gets back to the old version from his short trip to the new version, the SDK will fail to load the data from the new scheme it does not know about yet. The exact implications are to be cleared, though it is probably clear that the user will not be able to access his channels anymore.

In my opinion there are two strategies to handle such a situation: either ensure a force-reload performs a full mature update or prevent the update. Both approaches come with the challenge how to detect it. I can only repeat myself: what we do here is not a common thing and we have to fight against the current.

Acceptance criteria

• decide on strategy to solve the problem
• figure out how to detect this issue in the application
• implement handling of issue
• establish end-to-end tests

Tasks

• [ ]

[andrevmatos]

We define critical as bugs that can end to loss of user's funds, and I don't think this fits, although on an edge case (user force-reloading exactly when there's an update pending), it can lead to poor UX.

Could we check the IDB directly, to see if there there's a version different/older than the one we just loaded, and either trigger a normal reload or disable Connect button until the user does?

[weilbith]

Andre and I discussed this issue also in regards of having more issues where the browser directly loads the version from the server. We came to the conclusion that it is best to develop a generic solution that prevents this issue on a higher level. This means once the service worker as installed a local version the related version number will be persisted too. When the dApp loads, it will verify itself if it is the expected version that was installed. If not it will block the UI and resolve the issue. Andre and I figured out that it helps to unregister the current service worker and reload the tab. This is the same approach as we handle mandatory updates (when the client is broken). Just that here we just do it automatically. The user might see a quick flicker of the dApp after loading. This is very fast and should never bother the user.
The initial loading and update mechanism should work like the general update mechanism. The version information will be deleted. If the dApp loads and does not find a persisted version information it will assume it got initially loaded or an update was triggered and always loads successfully.
This also aligns with the feedback of Kamal that the strategy must be to prevent any updates the user has not manually confirmed.