Work with reconnects and site updates seamlessly

[slmnio]

Whenever the dev site is updated, the data server is restarted through PM2. This means all of the cached data is emptied and all clients must reconnect.

However, whilst clients do automatically reconnect, they don't rejoin the rooms (ie item updates) so the clients are essentially frozen in time until they are force refreshed.

A good fix for these would:

• Implement rejoining rooms on client reconnect
• Re-send all data to ensure it is up-to-date.

As the server cache will be empty, it's important to check that re-sending the item data doesn't just send empty data, especially during a broadcast, especially since clients will reconnect instantly and the server has just restarted.

Potentially this could be done hand-in-hand with a full site reload when a new commit is pushed.

• Reload pages if they are running an old commit

We can use the commit number on the server and client to check if the version if the same. There is a discussion to be had about refreshing pages during broadcast - is it worth having a manual refresh option? Should it affect both website AND broadcast clients?

I feel that in theory it should be manual only to avoid messy reloads, but in practice it should be fine to have automatic reloads. If the update is pushed away from broadcast, there's no problem and it's wanted to have everything reload to test changes. If the update is close to or during a broadcast, these are usually emergency or late updates and having everything reload at once is desired over having broken or old code running.

[slmnio]

Commit requests all subscribed IDs (tracked by vuex & request code) any time it connects. I couldn't find any reconnect events firing so it uses the connect event.

Regarding point 2 on re-sending data: it'll re-send data if it reconnects during the server "re-cache". That is, the client will register the item IDs first, then as it loads the data to rebuild the cache (ie the item cache changes from null to data), it will re-send that out.

There's a potential race condition where the client requests an update after it has been first-loaded on the server and the update wouldn't be sent. There's no reason why it couldn't trigger an update in the subscribe-multiple event handler.

[slmnio]

Closing this at the moment. I don't think reloading on commits is really needed now since we have a good separation of local/dev-stage/live. Potentially this could be useful during events but the rebuild time is fast and lots of issues can be fixed with the live CSS.