I don't know precisely what happened. The way things work roughly is that, MM enters the "victory" phase, which is where you get the report about the status of all the units and whether they're dead or not, and who killed what, etc. When you click done, the victory phase ends, the game's state is reset, the server sends a packet to the client to clear it's entities, and then it transitions to the lounge phase. When this lounge phase transition happens, a game event is fired that MekHQ catches. It checks for a transition from the victory to lounge phase (well, checks for a transition out of the victory phase but the only transition out of the victory phase is the lounge phase). Then, MekHQ goes about resolving the scenario. It gets the list of entities from the client and uses their state to populate the dialog.
If you'll notice, the first thing the server does when ending the victory phase is clear the game's state, which clears the list of entities, and sends a packet to the client to clear the list of entities. This code has been unchanged for a while. My guess is that, the time between the client receiving and processing this packet to clear the entities was longer than the time it took MekHQ to ask for the entity list. The socket communication on the client and server used to be a non-blocking busy-wait loop, that was something like, "wait 100ms, is there any comms? No, wait another 100ms... any comms?..." etc. Now it's a separate blocked thread that sits there quietly waiting for their to be comms, a packet is received, gets pushed into a queue and the packet handling thread gets notified that there's a new packet. So now there's no longer this 100ms delay between checking for packets.
There are a couple ways you could solve this. The one we chose was to add a new game event called GameVictoryEvent. When ending the victory phase, this event gets fired before the game's state is reset. MekHQ then listens for this event, and resolves the scenario before any game state resets happen.
