Too many chips at end of tournament

[ctm]

Add code that checks the number of chips in play at the start and end of every hand and also find and fix the bug that caused this evening's game (4935) to end with too many chips.

At the end of this evening's tournament, I had 420,900 chips. It was a Dealer's Choice tournament where everyone started with 60,000 and there were seven players, so a bug introduced 900 chips. This is completely unacceptable.

FWIW, we went years without anything like this, but when I decoupled action from players and moved it to seats, I introduced a bug (#1255) that caused chips to go missing. That bug was embarrassing enough, but at least a warning showed up in the logs. There is no warning in the logs for today's issue.

I strongly suspect this is due to table splitting and I also believe that I'll be able to find and fix the bug just by examining the logs, but that's insufficient. I also need to figure out why my consistency check didn't spot the error and fix that and also introduce a new consistency check that is run at the start and end of each hand.

FWIW, I want to get more people to play on the site, but if I were to go to a poker site and see missing or added chips, it would turn me away.

Now that I know what the problem is, here are the things I need to do:

• [x] don't duplicate the solo ante (that alone fixes this bug; eveything that follows is redundancy to avoid brown bag bugs)
• [x] have the RunningEvent know how many chips are in play:
  • [x] add a field
  • [x] populate it at the start
  • [x] add to it when people:
  • [x] redeem lammers
  • [x] rebuy
  • [x] add_on
  • [x] enter late
  • [x] re-enter (automatically happens as part of entering late)
  • [x] subtract from it when people quit
• [x] at the start of the hand:
  • [x] check to see if there's a solo ante (there never should be)
  • [x] check to see that the chip totals are correct
• [x] at the end of the hand:
  • [x] check to see that the solo ante has been cleared out
  • [x] check to see that the chip totals are correct

[ctm]

This is probably Table::dup duplicating the big blind ante. I realized this in my sleep but haven't had a chance to check yet.

[ctm]

Sure enough, dup duplicates solo_ante, and the first hand (383984) of the new table (5529) has a big blind ante of 900, which is the amount we ended up having extra. However, looking at the code for collect_antes, it's not immediately obvious to me how having a value in solo_ante before antes are collected would result in more chips in the pot, since collect_antes explicitly sets up solo_ante. So, I'll need to dig deeper.

FWIW, when I explicitly added the line to duplicate solo_ante, I was thinking solo_ante was just saying which seat needed to ante.

[ctm]

Found it. The first hand of table 5529 was not 383984. I mistakenly thought it was because that's the hand where the players moved and that does create rows in public_table_messages where hand_id is 383984 and table_id is 5529, but those are just player motion rows. The first hand was 383985, which is really a pseudo hand where the game was chosen and the next game that was chosen (1200 2400 (300) Stud (High/Low Eight Qualifier)) didn't have a solo ante, however, the misduplicated solo ante was then counted toward the pot because there is nothing in the new hand setup that checks for and clears an errant solo ante (because of course, that can't happen!).

So, I'm going to create a set of check-boxes for what I need to do to both fix this particular problem and also make sure it doesn't creep in again.

[ctm]

I'm deploying this now. I haven't yet added the extra instrumentation to my re-entry-1241 branch, but I'll do that once my deploy is done.

[ctm]

Turns out the re-enter branch didn't need any extra instrumentation because re-entering runs through the late registration code which I already instrumented. Ship it!