A transient "verification pending" refusal on socket rejoin drops the lobby and replays the whole run mid-match

Start with networking/nakama_lobby.lua and trace schedule_rejoin and with_socket; then read networking/connection.lua around start_launcher_verification. The issue identifies ui/reconnect_prompt.lua, api/playback/rejoin.lua, and the fix/live-run-reattach branch as the live run recovery path. Confirm which proposed fixes are still needed, then test a two-player disconnect and rejoin during a PvP blind; done means the lobby recovers without replaying over the live run and the player gets a notice if the match is gone.

Summary

Players report a "Checking your game..." overlay appearing at random during a match, followed by the whole game replaying from the start. It usually ends in a softlock, with the player left in a singleplayer/practice-style lobby outside the PvP blind.

Traced from one affected player's Lovely log (lovely-2026.11.04-11.33.54.log) plus the code. The code path is solid; the exact trigger on the server side is inferred (see "Not confirmed").

What happened (log timeline)

12:20:22  [nakama_lobby] socket error: standing_refused:{"reason":"verification_pending", ... "Launcher verification is still pending. Try again in a moment."}
12:20:22  [nakama_lobby] lost lobby EGLWG: standing_refused:{"reason":"verification_pending", ...}
12:20:34  replay starts (get_next_tag_key diagnostics)
12:20:40  playback hand_result mismatch: recorded=25 real=0   (x4, see note below)
12:21:40  ERROR :: MULTIPLAYER :: No next blind context

The replay starts about 12s after the refusal, which matches the up-to-15s launcher-verdict wait (S.VERDICT_WAIT_SECONDS).

Cause (three problems chained together)

1. A transient refusal is treated as final. After a socket drop, schedule_rejoin (networking/nakama_lobby.lua) retries match_join on a backoff, but only for transport failures. Any other error goes to follow_seat, and if the server still reports the same match it calls lose(err), which tears the lobby down. verification_pending says "Try again in a moment" but takes that final path, so a lobby that is still seated is destroyed.
2. Launcher verification is not refreshed when the lobby socket is reopened. start_launcher_verification is called only on first login (networking/connection.lua:467) and from verify_again. with_socket in nakama_lobby.lua does not restart it, so the rejoin can hit the server with no current verdict. (Inferred: the server's rule is not in this repo.)
3. The reconnect flow assumes any seat with a recorded run means a relaunch. lost -> show_rejoin_refused -> "Checking your game..." -> verify_again -> reconnect_to -> MPAPI.playback.rejoin (ui/reconnect_prompt.lua, api/playback/rejoin.lua). That flow is the crash-recovery path. It boots a second local run (as a practice lobby) over the run still on screen, fast-forwards the log into it, and only swaps in the real lobby in go_live. If the replay does not finish, the player stays in the local lobby. That is the "singleplayer lobby" players describe.

Related smaller findings

• Match not found shows no message. In the same log (11:55:44, lost lobby QKUYU: Match not found) the match really was gone. Giving up is right, but the lost handler in api/lobby/nakama.lua shows a notice only for a forfeit, a timeout, or a standing refusal, so the player is left in an orphaned run with nothing on screen.
• The hand_result mismatch ... real=0 warnings are a false positive, not replay drift. The HAND_RESULT handler in the PvP mod compares against PVP.GAME.score, which is set only by PVP.ACTIONS.play_hand, and that is skipped in practice mode (which the rejoin replay uses). So the field is always nil. This is in the PvP repo and is tracked there.
• Possibly related to #58 (reconnecting leaving game speed at 64x), since both involve the rejoin fast-forward. Not verified.

Proposed fixes

1. Retry verification_pending instead of giving up. In schedule_rejoin, treat it as retryable: start launcher verification once, then retry within the grace window. Only permanent reasons (mods_not_allowed, verification_failed, a forfeit) should call lose().
2. Verify before the join. When with_socket reopens a socket for a lost match, restart launcher verification and wait for the verdict before sending match_join.
3. Do not run the crash replay over a live run. If only the lobby was lost and the run is still on screen and recording, rejoin the seat into that run. Keep the fast-forward for a real relaunch. This is implemented on branch fix/live-run-reattach (commit 0d99dfe), no PR opened.
4. Tell the player when the match is gone (Match not found), and offer to leave the run.

The branch change remembers the lobby when it is lost with its run live and recording (MPAPI.playback.remember_dropped_lobby). rejoin() in ui/reconnect_prompt.lua then calls MPAPI.playback.reattach_live_run, which takes the seat back without a fast-forward. It carries over the unsent replay events and the gamemode instance from the old lobby. It does not address 1, 2 or 4.

Not confirmed

• Server-side rule. I could not see why the server reports verification_pending after a rejoin (whether the verdict is per socket session or has expired). Fixes 1 and 2 are written to work either way, but the server repo should confirm.
• The branch has not been run. It only parses as Lua. It needs a two-player test: drop the connection during a PvP blind, then rejoin.
• Replay events recorded while no lobby exists are not recovered. Only events kept on the old lobby object are resent, so the server's log may have a gap there. How the server treats that (end-of-match hash check) is unknown.
• PvP's attach hook on a live run. It calls PVP.setup_lobby_mirror, which I have not checked for resetting score, timers or ready state mid-blind.
• The trigger for the original socket drop is not visible in the log.