late registered player didn't see cards

[ctm]

Fix the race condition that caused jzk to be an observer rather than a player.

i just joined (late) and was sat at a table but my cards were never shown to me (backs only) then I timed out.

• [x] Don't delete the table session id from local storage after retrieving it
• [x] Create and send a Usurped message to the current client when a new web socket is bound to an existing table session
• [x] When it's usurped, have Table
  • [x] put up a message
  • [x] close its web socket
  • [x] close itself
• [x] Create an issue for deleting stale table session ids from local storage

[ctm]

FWIW, jzk didn't have a pop-up blocker interfere. The SQL I used to determine that was select lobby_requests.id, nick, received_at at time zone 'america/denver', request from lobby_requests join players on player_id = players.id where variant = 27 order by received_at desc limit 10; and it shows that only 3 players had pop-up failures this evening.

I've already scanned the logs for warnings and seen none (other than Illegal SNI hostname received).

I'll dig deeper tomorrow to look at the seating related messages.

[ctm]

The traffic logs show jzk did not open an observer window. They do show, however, that the table window was opened three times. Unfortunately, the traffic logs were lacking timestamps (#1387), but it should be easy enough to poke around in the database logs and find the timestamps in the seating related messages.

I'll also send some email asking for more details.

[ctm]

So, I can see the Lobby SitAt message in private_lobby_messages. It has id 475605. However, there's no corresponding entry in sit_request, which makes me think that the /event/5230/player/10635 path was taken to be an observer, rather than a login request.

In Table::create, we pull the table session id out of local storage and delete it. That would mean if the same url is opened a second time before the session id is re-written to local storage, the second table will be an observer. I didn't think this would happen though, due to the url only (in theory) being hit again via another SitAt request. However, in jzk's cae, there's only one SitAt request, but his event/player path is opened three times in what might be rapid succession, but I can't tell from the access logs due to missing timestamps.

I'll continue poring through the database logs. They have timestamps, but I believe we don't log much (anything?) about observers because we want to allow tens of thousands of them without it hammering the db.

[ctm]

Looking closer at the access logs, even without timestamps, I can see that the event player path is opened three times, without any intervening activity from any other connection and that afterward two web sockets are closed in close succession, which could be a table and a lobby, but is, IMO, more likely two tables, one of which is the initial one that would be jzk as a player, the other being an anonymous observer.

[ctm]

Tuns out, if I fire up a demo on craftpoker.com and then hammer Clover-R to refresh the table window of one of the demo players, I can get a white screen of death, which I'm hoping is the same problem. Demo connections are slightly different from regular connections, which may explain white screen vs. silently becoming an observer, but since I can reproduce the white screen problem, I can fix it and then use my judgment to make an educated guess as to whether it's the same problem.

[ctm]

I've deployed my fix for the race condition that I think bit jzk. Unfortunately, that does not fix the white screen of death (#1390).