Ningún mensaje se da por mandado hasta que el server lo confirma

[ErickUser1]

Qué pasaba

Con la sala "conectada", un mensaje se mandaba y se olvidaba. Si el socket ya estaba muerto sin que nadie lo supiera, el mensaje se perdía sin ninguna nota:

• En los primeros segundos de un corte de red, hasta que socket.io lo detecta con sus pings.
• Con el "Offline" de DevTools, para siempre: no cierra el websocket abierto.
• Con un corte más largo que el límite de socket.io (unos 45 s): la conexión se cierra con el mensaje adentro.

La cola del #104 solo cubría el caso en que la sala ya sabía que no había conexión.

Cambios

Server (index.ts, manejador de chat)

• Confirma cada mensaje (ack). Responde ok: false solo cuando vale la pena reintentar (todavía no está en la sala); lo que nunca va a entrar, como un adjunto inválido, se confirma igual.
• Recuerda los últimos 200 ids por sala y reconoce un reintento de algo que ya llegó: lo confirma sin repetirlo.

Front (App.tsx)

• Todo mensaje (el de la portada, los normales y los pendientes) entra a la cola de la pestaña (Lo escrito sin conexión sobrevive a una recarga y se queda en su sala #104) con un id, y sale de ahí solo con la confirmación.
• Sin confirmación en 6 s se muestra como pendiente ("se envía en cuanto vuelva"), se fuerza la reconexión, y al volver a entrar se reintenta todo lo pendiente en orden.
• Con los eventos offline/online del navegador, se desconecta al instante y se reconecta al volver, sin esperar a los pings.

Cómo se probó

Playwright contra el server real (agente simulado), con un proxy TCP entre navegador y server que puede congelar la conexión sin cerrarla (socket zombi) o congelar solo la bajada (llega, pero se pierde la confirmación), y con la emulación de red de DevTools:

Escenario	main	rama
3 mensajes seguidos, red normal	ok	ok
Offline de DevTools: se ve la nota de pendiente	no	sí
Offline de DevTools, recargando antes de volver	llega	llega
Socket zombi: pasa a pendiente con su nota	no	sí
Llegó pero se perdió la confirmación: sigue habiendo uno	uno	uno (sin duplicar)
Corte de 60 s (más que el límite de socket.io)	se pierde, sin nota	llega una vez

Regresiones, en la rama: cola del #104 (casos A, B y C), primer mensaje del #105 (persona nueva y con nombre), dos personas en Multijugador (#100), npm run typecheck, npm run build y las 8 demos.

Límite conocido

Los ids recibidos viven en memoria. Si el server se reinicia justo entre recibir un mensaje y confirmarlo, el reintento podría salir dos veces. Es mejor que perderlo, y está anotado en el código.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HJ5oT2Xm3VZMvbPAcgKbz4

---

Generated by Claude Code