Mantener vivo el chat cuando el móvil se duerme

El agente de Mythex puede trabajar durante minutos en una sola petición, y es muy posible que estés mirando desde el móvil, que se bloquea, cambia de app y cambia de red mientras trabaja. Dos fallos hacían que eso saliera mal. En uno, el chat trataba cada señal de «la página vuelve a ser visible» como prueba de que su conexión había muerto, y entraba en bucle hasta quedarse en «Conectando…». En el otro, un móvil que se durmió durante la primera respuesta de un chat nuevo volvía a mostrar solo los primeros fragmentos, hasta que se recargaba la página a mano. Ambos están arreglados.

Cómo sigue el chat un turno en marcha

Mientras el agente trabaja, el chat mantiene abierto un stream desde nuestros servidores: cada paso (un pensamiento, una llamada a herramienta, un trozo de la respuesta) llega como un evento. Si el stream se corta, el chat se reconecta y el servidor reproduce los eventos recientes desde un buffer que guarda los últimos 120 segundos. Cuando termina el turno, el chat también pide al servidor el historial guardado y concilia lo que mostraba con lo que se almacenó. Ese último paso atrapa lo que el stream se haya perdido.

Para distinguir una conexión viva de una muerta cuando no pasa nada, el servidor envía un pequeño «ping» cada 15 segundos.

Fallo 1: despertar mataba un stream sano

Los navegadores avisan a la página cuando vuelve a ser visible: tras cambiar de pestaña, tras desbloquear la pantalla. Nosotros usábamos esa señal como pista para comprobar la conexión, y en la práctica para abortar el stream y reconectar, suponiendo que había muerto mientras estaba oculto.

En móviles y en navegadores integrados, esos eventos se disparan mucho más a menudo de lo que mueren los streams: cada cambio de pestaña, cada desbloqueo, y en algunos navegadores integrados cada pocos segundos. Cada uno abortaba un stream perfectamente sano. El chat se reconectaba, reproducía, volvía a ser abortado y terminaba atascado en «Conectando…». Entonces decía que el turno había terminado mientras el agente seguía trabajando.

La solución: juzgar el stream por si está hablando

Ahora el chat registra cuándo recibió algo por última vez cada stream de cada proyecto: eventos y pings de 15 segundos por igual. Una señal de «visible de nuevo» solo aborta un stream que lleva 25 segundos en silencio: más que el intervalo de ping más un salto lento de red, de modo que un stream vivo nunca cumple la condición. Las pruebas comprueban que un ping cuenta como señal de vida, y que un stream que acaba de hacer ping no se trata como muerto.

La regla que sacamos de ello: la visibilidad de una página dice algo sobre la página, no sobre la conexión de red. Pregúntale a la conexión.

Fallo 2: media respuesta después de que el móvil se despertara

Este lo pudimos reproducir siempre en el simulador de iOS:

1. Inicia un chat nuevo y envía una petición que tarde un rato.
2. Deja que el móvil se duerma durante la construcción.
3. Vuelve cuando el turno ya ha terminado y el buffer de reproducción de dos minutos ha caducado.

El chat mostraba los primeros bloques de la respuesta, marcados como terminados, y se quedaba así hasta que recargabas la página.

Por qué

Un chat nuevo no tiene hilo (su conversación guardada) hasta que el primer mensaje lo crea. Eso ocurre dentro de la función de envío, después de que el envío ya había capturado el paso de conciliación, que seguía creyendo que no había hilo. Así que al final del primer turno de un chat nuevo, la conciliación no veía ningún hilo y volvía en silencio sin pedir nada.

Normalmente nadie lo notaba, porque el stream ya había entregado el turno completo. Pero un móvil que se durmió durante el turno y volvió después de que caducara el buffer de 120 segundos no podía recuperar los eventos que faltaban desde el stream, y la conciliación que debía llenar el hueco nunca se había ejecutado.

La solución

• El envío le dice a la conciliación a qué hilo pertenece el turno, así que el primer turno de un chat nuevo se concilia como cualquier otro. Si para cuando llega la respuesta ya has abierto otro chat, el resultado se descarta en lugar de mostrarse en el sitio equivocado.
• Una conciliación fallida se reintenta. Un móvil que se despierta con mala conexión puede encontrar el turno terminado y luego no poder obtenerlo. Eso ahora queda registrado, y el chat vuelve a pedirlo cuando la pestaña se muestra de nuevo o cuando regresa la red.
• «Trabajó durante» es honesto. Cada respuesta muestra cuánto tiempo trabajó el agente. Si la pestaña nunca vio el mensaje de fin de turno del servidor, antes lo rellenaba con su propio reloj, que contaba desde Enviar hasta que el móvil se despertó, incluido el tiempo fuera. Esa cifra ahora se marca como estimación y se reemplaza por la duración guardada cuando llega el historial.

Qué aprendimos

• Prueba en el dispositivo que la gente usa, de la forma en que lo usa. Ambos fallos vivían en el hueco entre «un stream que funciona» y «un móvil en el bolsillo».
• Una vía de respaldo que nunca se ejecuta no es un respaldo. El paso de conciliación existía precisamente para este caso, y lo omitía en silencio.
• Reintenta también la recuperación. El momento en que el móvil despierta es a menudo cuando su conexión está peor.
• No presentes una suposición como un hecho. Una duración medida con el reloj equivocado es peor que ninguna; hay que etiquetarla o reemplazarla.

El mismo trabajo también ordenó algunas cosas que verás mientras corre un turno: los pasos de shell se etiquetan con el comando que realiza el trabajo en lugar de con cd, las capturas de pantalla en el chat conservan la esquina superior izquierda de la página y encajan en la columna, y un proyecto nuevo recoge su nombre generado sin recargar.

Si estás construyendo tu propia app para móviles, nuestras guías sobre cómo crear una app web adaptada al móvil y apps nativas frente a aplicaciones web progresivas cubren lo básico. Más información sobre el propio chat está en la documentación del chat.