cancellable y cancel: darle nombre a un efecto

Cancelar exige, antes que nada, poder señalar. Y el candidato obvio —la Task que el runtime creó— es justo el que no sirve: esa tarea nace dentro del store, vive fuera del reducer y desaparece sola; el reducer, que es una función pura de estado y acción, no la ve ni debería verla. La solución de TCA es desplazar el problema al único terreno donde el reducer se mueve con soltura, el de los valores: al efecto se le adjunta una identidad —cualquier valor Hashable— y el store mantiene un registro que asocia identidades con tareas vivas. A partir de ahí, cancelar deja de ser una operación sobre un objeto concurrente y se convierte en lo que el reducer sabe hacer: devolver un valor que dice qué nombre hay que dar de baja.

.cancellable(id:): registrar el efecto bajo un nombre

El operador se encadena al efecto y devuelve otro efecto, envuelto. Cuando el store lo ejecute, además de arrancar la tarea, la anotará en su registro bajo la identidad que le diste; cuando la tarea termine por su cuenta, la desanotará.

@Reducer
struct Busqueda {
  @Dependency(\.clienteBusqueda) var cliente
  private enum CancelID { case peticion }

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .buscarPulsado:
        state.cargando = true
        return .run { [consulta = state.consulta] send in
          await send(.respuesta(try await cliente.buscar(consulta)))
        }
        .cancellable(id: CancelID.peticion)

      case let .respuesta(items):
        state.cargando = false
        state.resultados = items
        return .none

      case .cancelarPulsado:
        state.cargando = false
        return .cancel(id: CancelID.peticion)
      }
    }
  }
}

Repara en el detalle de la captura [consulta = state.consulta]: el estado es inout y no puede cruzar la frontera de una closure asíncrona, así que el valor se copia antes de que el efecto exista. Es la misma disciplina de siempre —el efecto se construye con datos, no con acceso al estado vivo— y aquí resulta doblemente sana, porque un efecto cancelable puede sobrevivir varios ciclos del reducer y leer estado mutable desde dentro sería una carrera de otra clase.

flowchart LR
A[accion buscarPulsado] --> R[reducer devuelve Effect]
R --> C[cancellable con id peticion]
C --> S[store arranca la Task]
S --> REG[registro identidad a tarea viva]
A2[accion cancelarPulsado] --> CN[Effect punto cancel id peticion]
CN --> REG
REG --> K[la tarea se da de baja y muere]
style REG fill:#f9e2af,color:#11111b
style K fill:#f38ba8,color:#11111b

Ese registro es el corazón del mecanismo y conviene imaginarlo con precisión: un diccionario de AnyHashable a tareas vivas, alojado en el store y protegido para acceso concurrente. .cancellable(id:) inserta; el final natural del efecto elimina; .cancel(id:) busca y cancela. Nada de esto asoma al reducer, que sigue siendo una función pura: lo único que él manipula son valores que nombran entradas de ese diccionario.

.cancel(id:): dar de baja desde cualquier parte

.cancel(id:) construye un Effect como cualquier otro, y de ahí se derivan tres propiedades que se usan a diario. Se puede devolver desde una rama del reducer que no tiene nada que ver con la que lanzó el efecto, porque la identidad es un valor compartido y no una referencia capturada. Se puede combinar: .merge(.cancel(id: CancelID.reloj), .cancel(id: CancelID.sondeo)) apaga dos cosas a la vez, y .merge(.cancel(id: X), otroEfecto) apaga una y arranca otra en el mismo retorno. Y es idempotente: cancelar una identidad que no tiene nada vivo detrás no falla ni avisa, simplemente no hace nada, lo que te libera de comprobar antes si hay algo que cancelar.

case .pantallaDesaparecio:
  return .merge(
    .cancel(id: CancelID.reloj),
    .cancel(id: CancelID.sondeo)
  )

Hay una variante de grano más fino para cuando la cancelación debe ocurrir dentro de un efecto y no como retorno del reducer: withTaskCancellation(id:cancelInFlight:), la primitiva sobre la que está construido el propio .cancellable. Envuelve un fragmento async con la misma semántica de identidad, y sirve para el caso en que un solo .run hace varias cosas y solo una de ellas debe quedar bajo control externo. Es infrecuente y conviene que lo siga siendo: mientras el ciclo de vida del efecto coincida con el ciclo de vida de la tarea, .cancellable en el retorno es más legible y más fácil de auditar.

El patrón CancelID: identidades que no colisionan

La firma admite cualquier Hashable, y esa generosidad es una trampa. Si identificas con "busqueda", ese literal es igual a sí mismo en toda la aplicación: dos features distintas que usen la misma cadena comparten entrada en el registro, y cancelar una apaga la otra. El fallo es silencioso, aparece solo cuando ambas pantallas están vivas a la vez y no lo detecta ningún compilador. La convención de la comunidad lo cierra de raíz.

private enum CancelID { case peticion, sugerencias, reloj }

Funciona por una razón de tipos, no de nombres: dos enum declarados en features distintas son tipos distintos, aunque ambos se llamen CancelID y tengan un caso peticion. Al meterlos en un AnyHashable, la identidad del tipo forma parte de la comparación, de modo que Busqueda.CancelID.peticion nunca es igual a Perfil.CancelID.peticion. El private refuerza la disciplina impidiendo que nadie de fuera cancele tus efectos, y el enum sin valores asociados da, gratis, Hashable sintetizado y exhaustividad al leer el archivo: los efectos de larga vida de la feature están enumerados en una sola línea.

El caso paramétrico merece una mirada extra, porque es donde más se equivoca la gente. Dentro de un forEach, si todas las filas registran su efecto bajo la misma identidad, la segunda fila que cargue matará el efecto de la primera —o, con cancelInFlight, se lo comerá sin avisar—. La identidad tiene que incluir aquello que distingue a la instancia.

private enum CancelID: Hashable { case carga(Fila.State.ID) }

case let .fila(id, .aparecer):
  return .run { send in
    await send(.fila(id, .datos(try await cliente.detalle(id))))
  }
  .cancellable(id: CancelID.carga(id))

Qué significa cancelar de verdad

Cancelar en Swift no interrumpe nada por la fuerza: marca la tarea, y la tarea muere en su siguiente punto de suspensión, cuando el await correspondiente lanza CancellationError. Esto tiene dos consecuencias prácticas. La primera es que un efecto que hace trabajo síncrono largo —un bucle de cálculo sin await— no se entera de que lo cancelaron; si vas a ocupar la CPU, comprueba Task.isCancelled o llama a try Task.checkCancellation() de vez en cuando. La segunda es que la muerte no es instantánea: entre el .cancel(id:) y el último aliento del efecto hay un intervalo, breve pero real, y durante él la tarea sigue existiendo.

return .run { send in
  for pagina in 0..<100 {
    try Task.checkCancellation()
    await send(.pagina(try await cliente.pagina(pagina)))
  }
}
.cancellable(id: CancelID.descarga)

Falta una pieza de comportamiento que sorprende y es deliberada: cuando un efecto muere por cancelación, el catch: de .run no se ejecuta. TCA distingue el CancellationError de un fallo real y lo descarta en silencio, porque una cancelación no es un error del dominio: nadie quiere pintar una alerta de red porque el usuario cambió de pantalla. La consecuencia de diseño es limpia: un efecto cancelado no emite ninguna acción, ni de éxito ni de fallo, y por tanto no puede tocar el estado. Si necesitas que el estado registre la interrupción —apagar un indicador, marcar algo como abortado—, hazlo en el reducer, en la misma rama que devuelve el .cancel(id:), que es exactamente donde consta la intención.