Por qué cancelar: la respuesta obsoleta que pisa tus datos

Un usuario teclea swift en tu buscador. Cinco pulsaciones, cinco acciones, cinco efectos, cinco peticiones a la red. La cuarta petición —la de swif— pasa por un servidor congestionado y tarda 900 ms; la quinta —la de swift— cae en caché y vuelve en 40. En pantalla aparecen los resultados correctos durante medio segundo y luego, sin que nadie toque nada, se sustituyen por los de una consulta que el usuario ya abandonó. Ningún reducer se equivocó: cada acción hizo exactamente lo que decía hacer. Lo que falló es que el sistema no tenía forma de saber que uno de esos efectos había dejado de importar. Este nivel entero trata de esa forma, y esta lección empieza por lo único que justifica el resto: entender con precisión qué se rompe cuando un efecto sobrevive a su propia relevancia.

La carrera clásica del buscador

El código culpable es tan corriente que resulta difícil verlo como sospechoso. Una acción por cada cambio de texto, un efecto por cada acción, y una acción de vuelta con los resultados.

case let .consultaCambiada(texto):
  state.consulta = texto
  return .run { send in
    let items = try await cliente.buscar(texto)
    await send(.resultadosRecibidos(items))
  }

case let .resultadosRecibidos(items):
  state.resultados = items
  return .none

Lee resultadosRecibidos con lupa: escribe en state.resultados cualquier lista que le llegue, sin preguntar de dónde viene. Y no puede preguntarlo, porque en la acción no viaja esa información: [Item] no dice a qué consulta pertenece. El reducer, que es puro y determinista, hace lo correcto con lo que tiene. El defecto no está en su lógica sino en el vocabulario del dominio, que ha perdido por el camino el vínculo entre una pregunta y su respuesta.

sequenceDiagram
participant U as Usuario
participant S as Store
participant N as Red
U->>S: teclea swif
S->>N: buscar swif
U->>S: teclea swift
S->>N: buscar swift
N-->>S: resultados de swift en 40 ms
S->>S: escribe resultados correctos
N-->>S: resultados de swif en 900 ms
S->>S: sobrescribe con datos obsoletos

El diagrama deja al descubierto la asimetría: las peticiones salen en el orden de las pulsaciones, pero las respuestas vuelven en el orden que decida la red. El store aplica ambas con la misma obediencia, y como la escritura es destructiva, gana la última en llegar. La pantalla acaba mostrando la respuesta a una pregunta que el usuario ya no está haciendo.

Conviene además desconfiar del ejemplo del buscador, porque su fama hace pensar que el problema es de los buscadores. La forma del defecto es mucho más general: aparece siempre que una acción del usuario puede repetirse antes de que se resuelva la anterior y ambas escriben en el mismo sitio del estado. Un gesto de arrastre para refrescar que el usuario repite impaciente; un selector de filtros que dispara una recarga por cada toque; una pantalla de detalle que se abre, se cierra y se vuelve a abrir con otro identificador; una paginación que carga la página tres mientras la dos sigue en camino. En todos los casos hay una secuencia de intenciones y un único hueco donde escribir el resultado, y en todos, si no se hace nada, gana la respuesta más lenta en lugar de la intención más reciente.

El orden de salida no es el orden de llegada

Conviene resistir la tentación de tratar esto como mala suerte estadística. No hay ninguna capa del sistema que prometa que dos tareas independientes terminen en el orden en que empezaron, y hay muchas razones para que no lo hagan: rutas distintas, reintentos de TCP, multiplexación de HTTP/2 donde un flujo lento no bloquea a otro, cachés que responden algunas consultas al instante y otras no, o simplemente un servidor cuyo coste de búsqueda depende del término. Con concurrencia estructurada de Swift la situación es aún más nítida: cada .run es una Task propia, corren en paralelo sobre el pool cooperativo, y el runtime no impone ninguna relación de orden entre ellas.

Lo interesante es que el fallo no es intermitente por naturaleza, sino sensible a la latencia: aparece siempre que la diferencia de tiempos entre dos peticiones supera el intervalo entre dos pulsaciones. En tu máquina, contra un servidor local, esa condición casi nunca se cumple y el bug es invisible. En una red móvil, con un usuario que escribe rápido, se cumple varias veces por sesión. Es el peor perfil posible para un defecto: indetectable donde se desarrolla y frecuente donde se usa.

Hay algo más de fondo, y es lo que convierte esto en un problema de arquitectura y no de red. El reducer aplica una secuencia de acciones a un estado; su corrección se define acción a acción. Pero cuál es la última escritura válida es una propiedad del historial completo, no de un paso aislado. Cuando el orden de llegada deja de coincidir con el orden de intención, el sistema pierde la única referencia que tenía para decidir qué escritura debe prevalecer, y ninguna cantidad de pureza en el reducer la recupera.

Los parches que casi funcionan

Ante el síntoma, la reacción instintiva es filtrar a la salida: dejar que todas las respuestas lleguen y descartar las que ya no interesan. La versión más común compara la consulta al recibir, para lo cual hay que hacerla viajar dentro de la acción.

case let .resultadosRecibidos(texto, items):
  guard texto == state.consulta else { return .none }
  state.resultados = items
  return .none

Funciona, y por eso es peligroso: resuelve el caso visible y deja intactos los demás.

De las cuatro objeciones, la tercera es la que convierte el parche en una trampa. Un filtro que falla a veces es peor que ninguno, porque genera confianza: el equipo da el bug por cerrado, el caso raro se reporta meses después como algo distinto y nadie relaciona ambos informes. Los remedios parciales en concurrencia tienen esa firma característica —reducen la frecuencia del síntoma sin eliminar la causa— y esa reducción de frecuencia es exactamente lo que impide que el defecto se vuelva a reproducir en condiciones controladas.

El parche siguiente sustituye la comparación por un contador monótono, que sí cierra el agujero del texto repetido.

case let .consultaCambiada(texto):
  state.consulta = texto
  state.secuencia += 1
  return .run { [texto, n = state.secuencia] send in
    await send(.respuesta(n, try await cliente.buscar(texto)))
  }

case let .respuesta(n, items):
  guard n == state.secuencia else { return .none }
  state.resultados = items
  return .none

Es correcto, y merece la pena mirar por qué lo es: acabas de reimplementar a mano, dentro de tu dominio, una noción de identidad y vigencia de un efecto. El campo secuencia no describe nada del negocio —no es un dato que ningún diseñador pidiera, ni que ninguna pantalla muestre—, es contabilidad de concurrencia disfrazada de estado. Eso ya existe en la arquitectura, está probado, funciona igual para búsquedas que para temporizadores y sockets, y no obliga a contaminar cada Action y cada State con metadatos de fontanería. Cuando un patrón te empuja a inventar tu propio sistema de versiones, casi siempre es señal de que el mecanismo correcto vive un nivel más abajo.

Cancelar es corrección, no ahorro

La política correcta invierte el planteamiento. En vez de dejar correr el efecto obsoleto y filtrar su resultado, se le impide producirlo: en el instante en que la nueva consulta llega, el efecto anterior se detiene. Nadie tiene que decidir después si su respuesta era vigente, porque no habrá respuesta.

private enum CancelID { case busqueda }

case let .consultaCambiada(texto):
  state.consulta = texto
  return .run { send in
    await send(.resultadosRecibidos(try await cliente.buscar(texto)))
  }
  .cancellable(id: CancelID.busqueda, cancelInFlight: true)

Ese cancelInFlight: true —que las lecciones 2 y 3 desarman pieza a pieza— establece un invariante fuerte: como mucho hay un efecto de búsqueda vivo en todo momento. Con ese invariante, resultadosRecibidos recupera su inocencia; la única respuesta que puede llegar es la de la consulta en curso, y escribirla sin preguntar vuelve a ser correcto. Fíjate en la forma del razonamiento, porque se repetirá todo el nivel: no hemos añadido una comprobación, hemos eliminado el estado del mundo que la hacía necesaria.

Merece la pena insistir en la palabra corrección, porque el discurso habitual sobre cancelación la vende como una optimización —ahorra red, ahorra batería, ahorra dinero de servidor— y esa venta se lee como algo deseable pero postergable. No lo es. Un buscador sin cancelación no es un buscador eficiente que gasta de más; es un buscador que muestra datos falsos, de forma intermitente, con más frecuencia cuanto peor sea la red del usuario. El ahorro de recursos es un efecto secundario agradable de haber arreglado un defecto de exactitud, y ordenar así las prioridades cambia cómo se prioriza el trabajo: esto no compite con las mejoras de rendimiento del sprint, compite con los bugs.