Check core.app._uuid and warn if repeated mismatch (no session affinity?)

[evnchn]

Motivation

In light of NiceGUI used in cloud with auto worker scaling, we found that the fact that NiceGUI needs session affinity isn't really well known and leads to quite some headscratchers.

#5395 (comment)

NiceGUI Wishlist (view)

Implementation

• Add core.app._uuid which is served HTML-land and checked SocketIO-land.
• If mismatch 3+ times, warn and ask for further retries.
• Should catch more than 1 worker: the more workers there are, there easier this gets triggered.

Progress

• I chose a meaningful title that completes the sentence: "If applied, this PR will..."
• The implementation is complete.
• Pytests have been added (or are not necessary).
• Documentation has been added (or is not necessary).

Final notes

Locally, to simulate the mismatch, do:

if server_id != core.app._uuid or True: # pylint: disable=protected-access

[falkoschindler]

@evnchn Thanks for the pull request, that's a great idea!

But we think the error should be shown on the server, not on the client. This would simplify the JavaScript code and provide opportunity to link to educational documentation for the developers.

[evnchn]

Concern 1: Not sure the detection accuracy on the server side.

Obviously wrong server_id from an incoming connection can be due to worker mismatch.

But it can also be due to a client which while it was disconnected from internet, the server has rebooted. And there can be infinitely many server_ids caused by this, as clients may be from an arbitrary number of server reboots ago.

I am not quite sure of a reliable heuristic which I can use to distinguish the former from the latter, and I chose browser-based detection because it's easier. If you have any ideas on detection on server side, please tell me.

Concern 2: Stopping browser infinite-reload is still necessary

The infinite reload may put great stress at the server hosting setup, and may manifest into large cloud bills if cloud was used.

So even if the warning is shown on the console, I think the client should still stop trying after 10 attempts or so.

[evnchn]

0c2db43:

• Detection accuracy is no worse than before, since on 3 - 20 failed connection attempts, client is just retrying to "spread the word to workers"
• Browser still stops at 20 reloads

I consider it a pretty good solution. I am not sure about the error messages though.

[falkoschindler]

Some tests seem to be failing. Let's see if a merge from main helps.
Anyway, I'll move it to version 3.5.