Hero hole cards render face down after ~1h on a table (auth signature never renewed)

Chiusa
#953 0 commenti 0 reazioni 2 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@bitcoinbrisbane ci sta già lavorando.

Dal 2/11/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

bug UI Week 2

Summary

Several nights recently, a seated player was dealt hole cards that rendered face down (card backs) to that player. Everyone else's view looked normal. A browser refresh fixes it immediately. Related symptom previously reported in #409 (closed without an identified root cause).

Likely root cause (inferred from code, ~80% confidence)

The per-player websocket auth is signed once per socket and never renewed. After ~1 hour, the chain rejects it, and the relay silently falls back to the public (fully masked) state.

  1. UI signs once. src/context/GameStateContext.tsx (block52/ui main, L302-310): on socket open, createAuthPayload() signs pokerchain-query:<unix ts> and sends a single subscribe {gameId, playerAddress, timestamp, signature}. Nothing re-signs while the socket stays open. The wake handler (L462-485) returns early for an open, live socket (L473), so a tab becoming visible does not re-sign either.
  2. Relay keeps the first signature forever. block52/pokerchain pkg/wsserver/server.go L806-810 stores playerId/timestamp/signature on the client at subscribe. Every broadcast (sendPersonalizedUpdate, L538+, and authedStateJSON in optimistic.go L159-186) reuses them.
  3. Silent masked fallback. On any error from the authenticated GameState / OptimisticGameState query, the relay falls back to the public Game query (server.go ~L462-473 and L565-568), where all hole cards are masked. No error is sent to the client.
  4. Chain 1h window. x/poker/keeper/query_game_state.go L47-56 (and query_optimistic_game_state.go L39) reject a timestamp more than 1 hour from block time.

So ~60 min after the socket opened, every update reaches the hero with their own cards as X, and the seat draws backs. A refresh re-signs, which is why it fixes it.

Possible trigger for it showing up now: #910 (fix for #867) stopped a browser offline blip from tearing down an open socket. Previously those blips likely forced reconnects, and each reconnect quietly re-signed. Sockets now live longer than 1h more often. This is unverified.

How to confirm

  • Relay logs for the affected player should show the authenticated query failing with timestamp must be within 1 hour of block time, followed by the public-query fallback.
  • Repro: sit at a table for more than 60 min without refreshing. Hole cards should go face down at about the hour mark.

Load impact of the fix

One extra read-only signed query per player every 30-45 min (re-subscribe returns a fresh snapshot). No indexer involvement, negligible device cost.

Proposed fix

  • Periodically re-sign and re-send subscribe on the same socket every 30-45 min. The relay already overwrites stored credentials on a new subscribe. Apply the snapshot as a normal state update, without bus.reset().
  • Re-sign and re-subscribe when the tab becomes visible again (visibilitychange).
  • Debounced safety net: if the hero is seated in a live hand and their own hole cards arrive masked (X/??), re-subscribe with a fresh signature once, with a debounce to avoid loops.
  • Follow-up for block52/pokerchain (relay): when a client's authenticated query fails, send an auth_expired event (or keep the last per-player state) instead of silently serving the public masked state, and log it clearly.

Code refs: block52/ui main 12b9a929, block52/pokerchain v0.1.206 da56cd6.

Lingua principale
TypeScript
Stelle
2
Fork
5
Merge medio
21h 50m
PR unite (30g)
104

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di block52/ui

Tutte le issue di block52/ui

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.