Teamlist cleared with multiple admin interfaces

[kmeesters]

It seems that the teamlist gets cleared when multiple admin interfaces are open. The issue may orginate from retrieving the teamlist. When the team page does not find a teamlist on the server it creates a new teams.json, potentially overriding the existing teams.json. This occurs when the page performs the check before the teams.json is successfully retrieved.

The issues does not occur when there is 1 admin interface and multiple referee interfaces. Note: it may been the high ping times of using an internet connection that contributes to the issues (less likely to occur if teamlist can be retrieved in time).

[kmeesters]

Perhaps a solution could be to prevent 'clients' to write new empty jsons to the server when a server is listed in the settings (in 'challenge') @poelstra

[poelstra]

This is a generic problem with the way we've currently set up the system. We've seen similar issues with two admin interfaces overwriting different subsets of the settings.

One of the big original use cases was for the app to function standalone, in which case there would be no central server. There would also not be the concept of 'multiple clients'.

We may need to rethink that approach a bit, and maybe even change the architecture to explicitly support client/server, where we could have a (trivial) implementation of the server part running in the webbrowser for the 'standalone' case. (e.g. saving files to localstorage, merging changes, checking for updated scores, etc.) It's all JS anyway.

One of the issues is that instead of just changes, whole files get written.

A quick fix, to make the issue less frequent, is to inform clients of updates to these files. They would then get reloaded, making overwrites more rare. This does have the issue that two people changing (maybe unrelated things) will cause one of them to loose their changes.

We could use MHub for broadcasting such change events (any maybe even just broadcast the whole file, too). To ease setup, we could even integrate an instance of MHub right into localserver.js (people would still be able to use another one, of course).

Alternatively (and maybe additionally), we could have a mechanism in which a save to the server only succeeds if the file was not changed in the mean time. E.g. that the client also has to supply some 'version' identifier (could be a number, the filetime, a hash of the contents, etc.) of what it knows was the last state of the file. This would still be kind of a hack, but at least it will give direct feedback that your changes were not saved due to someone saving the file before you.

However, I think the best fix would be to send changes around (e.g. add a team, remove a team, etc.). This in turn could cause a message to be broadcasted to all connected clients to refetch that data (or we could send the diffs, but I suppose that will be harder to ensure consistent state everywhere than just doing it on the server and sending whole snapshots around).

That best fix is (way) more work, though.

[kmeesters]

Just to add: with the eye on multiple modules (like judging who also use the teamlist) this might be preferred (along with the 'last state', in case clients connect later). But I'll leave it up to you and @rikkertkoppes. We can also think about modifying the process/instructions. Furthermore we may even separate the whole team-management out into a separate team-admin module (which was plannend anyway) Although that addresses only this specific issue.