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

Abierto
  • ¿Algo no está bien?
#59 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
lua
Área
api, backend-api-design

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Lua
Estrellas
10
Forks
8
Merge medio
1 d 18 h
PR fusionados (30 d)
20

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Balatro-Multiplayer/BalatroMultiplayerAPI

Todos los issues de Balatro-Multiplayer/BalatroMultiplayerAPI

Issues similares

Más issues de Lua

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.