Escribió «urgente» rápido y la pantalla le enseñó los resultados de «urg»

Nuria lleva soporte técnico interno. Escribe rápido, como cualquiera que teclea la misma palabra veinte veces al día. Un buscador de tickets sobre una tabla con miles de filas: cada letra dispara una petición al servidor y pinta lo que vuelve. Escribió «urgente» de un tirón, vio durante medio segundo los tres tickets correctos y, justo después, la lista cambió sola por los resultados de «urg». Sin tocar nada.

No era un fallo del servidor ni de la consulta. Las dos peticiones estaban bien hechas y las dos respondían con datos correctos, cada una a su propia pregunta.

La más nueva no siempre llega primero

Cada tecla lanzaba un fetch distinto y el componente pintaba lo último que le llegaba, sin preguntar de qué petición venía. «urg» tardó más en volver que «urgente» —cache fría en el servidor, un salto de red, daba igual la causa— y aterrizó después. El componente no tenía forma de saber que esa respuesta ya no servía para nada: solo sabía que había respuesta, y la pintó.

Con conexión estable no se nota nunca. Con una VPN corporativa de esas que varían quince milisegundos arriba o abajo, se nota cada tarde.

Qué le pedí al IDE local

Le pegué el componente de búsqueda entero a Elffuss Code y le pedí, en este orden:

• Un identificador que suba con cada petición nueva, y que la respuesta solo se pinte si su identificador coincide con la última petición emitida, no con la última recibida.
• Cancelar de verdad las peticiones que ya no hacen falta con AbortController, no solo ignorar su respuesta cuando llegue.
• Una tabla de órdenes de llegada posibles antes de tocar una línea: normal, invertido, una petición que nunca vuelve, y borrar todo el texto de golpe mientras dos siguen en vuelo.

El primer intento comparaba identificadores pero no llamaba a abort(), así que las peticiones fantasma seguían gastando conexión de fondo. Le enseñé la fila de la tabla donde se borra todo el texto —consulta vacía, cero peticiones pendientes que valgan la pena— y ahí salió que también hacía falta cancelar al vaciar, no solo al escribir una letra más.

El test que quedó no compara un resultado fijo: lanza las mismas cuatro peticiones con retrasos aleatorios en cada pasada y comprueba que, gane quien gane la carrera de red, lo que se pinta siempre corresponde a la última palabra que Nuria escribió.

El bug no estaba en cuál petición ganaba. Estaba en que ninguna sabía si ya no hacía falta.

Por qué esto no se pega en un chat ajeno

Para reproducirlo hacía falta el tráfico de verdad: las palabras exactas que se buscan en un sistema de tickets internos delatan de qué se queja la gente, qué cliente amenaza con irse, qué empleado busca su propia nómina. Un log de red con eso dentro es, de facto, un rato de conversaciones ajenas. Con el modelo corriendo en el navegador, sobre la GPU del propio equipo, pegué el tráfico tal cual sin plantearme si hacía falta tapar algo primero. No había a quién enseñárselo fuera de esa pestaña.