Discard problem in Super Stud

[ctm]

Investigate why ODB Phat Mack said "discard problem" in hand 398657.

FWIW, this may be an issue dan has reported in the past.

Dealing #398657: 800 1600 (300) Super Stud (High/Low Eight Qualifier) Everyone antes 200 1 > jpmassar 30550 200 [ ] [ ] [ ] [ ] 3c 2 luckbucket 10850 200 [ ] [ ] [ ] [ ] Ts 3 B 🐭GamboMouse 27000 200 [ ] [ ] [ ] [ ] 9h 4 smalltalkdan 29100 200 [ ] [ ] [ ] [ ] 4d 5 Chuck 14350 200 [ ] [ ] [ ] [ ] Ks 6 ODB Phat Mack 🎈🎈🎈 26950 200 [ ] [ ] [ ] [ ] 8c jpmassar brings-in for 300 We're now on Level 6 luckbucket folds 🐭GamboMouse folds smalltalkdan completes the 300 bring-in to 800 Chuck folds ODB Phat Mack 🎈🎈🎈 calls jpmassar calls 1 jpmassar 29750 1000 [ ] [ ] [ ] [ ] 3c 2 [luckbucket] 10850[ 200] 3 B [🐭GamboMouse] 27000[ 200] 4 smalltalkdan 28300 1000 [ ] [ ] [ ] [ ] 4d 5 [Chuck] 14350[ 200] 6 > ODB Phat Mack 🎈🎈🎈 26150 1000 [ ] [ ] [ ] [ ] 8c ODB Phat Mack 🎈🎈🎈 has gone on vacation ODB Phat Mack 🎈🎈🎈 discards 2 ODB Phat Mack 🎈🎈🎈 is back from vacation jpmassar discards 2 smalltalkdan discards 2 1 jpmassar 29750 1000 [ ] [ ] 3c 5c 2 [luckbucket] 10850[ 200] 3 B [🐭GamboMouse] 27000[ 200] 4 smalltalkdan 28300 1000 [ ] [ ] 4d 5s 5 [Chuck] 14350[ 200] 6 > ODB Phat Mack 🎈🎈🎈 26150 1000 [ ] [ ] 8c 7d ODB Phat Mack 🎈🎈🎈 asked for and gets 30 more seconds ODB Phat Mack 🎈🎈🎈 checks jpmassar checks smalltalkdan bets 800 ODB Phat Mack 🎈🎈🎈: discard problem

[ctm]

The messages that show when ODB's client was told that he needed to draw are:

mb2=> select id, received_at at time zone 'america/denver', substr(message::text, 0, 140), player_id from public_table_messages where hand_id = 398657 order by received_at;
select id, received_at at time zone 'america/denver', substr(message::text, 0, 140), player_id from public_table_messages where hand_id = 398657 order by received_at;
    id    |          timezone          |                                                                   substr                                                                    | player_id 
----------+----------------------------+---------------------------------------------------------------------------------------------------------------------------------------------+-----------
...
 10665914 | 2024-03-24 18:30:37.58155  | {"RemindDraw": [20000, {"Discard": [2, 2]}, "2024-03-25T00:30:57.566617254Z", 17, 20]}                                                      |          
 10665915 | 2024-03-24 18:30:57.568697 | {"Vacationed": 17}                                                                                                                          |          

The SQL to look for what the client sent is: select id, received_at at time zone 'america/denver', request from table_requests where table_session_id = 'REDACTED' order by received_at; and it shows that the client sent requests to clear the discard multiple times, but never sent the cards to discard. This means it's a client problem and not due to network lag.

Currently, the client doesn't send back "its side" of what happened, which prevents me from being able to diagnose this (and similar) problem purely from the logs we automatically collect. Eventually we'll have the client maintain logs that we can request, one way or the other. In the meantime, my guess is I can reproduce it by futzing around, perhaps on my own although if I can't reproduce it quickly, I'll send ODB Phat Mack email and ask for more info.

[ctm]

I just checked the code and setting discards to None is only done when changing the selected state of any card or when either the advanced "Stand Pat"/"Discard N" checkbox is unchecked or the "Undo Discard"/"Undo Pat" button is pressed. Since it was ODB's time to discard, he shouldn't have had an advance discard checkbox, only buttons.

[ctm]

I should have just tried to reproduce this before looking at the logs and code, because the problem is that the upcard is currently selectable, even though it can't be discarded and when it's selected it looks the same as when it's not. So, if you click on the upcard, and then select two other cards, it will think you have three cards selected and refuse to enable the discard button.

I suspect that Dan has told me about this and I have experienced it myself, but it fell through the cracks and I have CRS. Anyway, now that I strongly believe that's what bit ODB, I can fix it.

[ctm]

D'oh! That's what I get for using "selected" to represent both a card to discard as well as a stud upcard.

[master]% git diff
diff --git a/front-ends/web/src/table.rs b/front-ends/web/src/table.rs
index b981dc40..5e560ca3 100644
--- a/front-ends/web/src/table.rs
+++ b/front-ends/web/src/table.rs
@@ -3501,13 +3501,14 @@ impl SomeonesCards {
                 };
                 html! { {
                     for cards.iter().enumerate().map(|(i, card)| {
-                        let callback = if selectable {
+                        let stud_revealed = stud && card.revealed;
+                        let callback = if selectable && !stud_revealed {
                             link.callback(move |_| Msg::Select(i))
                         } else {
                             Callback::noop()
                         };
                         let card_no = Self::card_position(i, &gap_after);
-                        let stud_revealed = if stud && card.revealed {
+                        let stud_revealed = if stud_revealed {
                             " selected"
                         } else {
                             ""

Deploying now.