API y empresas

Cancelar una consulta de multas en curso

Cancelar detiene trabajo futuro; no deshace lo que ya terminó ni borra lo que una fuente contestó antes del pedido. Conviene declarar qué estados lo admiten y qué pasa con la cuota.

Por Marco Ferreiro ·

Línea de rodillos en un depósito con una barra bajada que retiene dos cajones, mientras otros tres ya pasaron al extremo final.

Una integración pide cancelar por motivos poco épicos: el operador cargó la patente equivocada, el lote se lanzó dos veces, la ventana operativa se cerró. Lo que casi nunca está escrito es qué significa ese pedido cuando el trabajo ya se repartió entre fuentes que responden a su propio ritmo.

Cancelar es una instrucción sobre trabajo futuro: puede evitar que se inicien tareas pendientes y, cuando la arquitectura lo permite, interrumpir las que están corriendo. No deshace lo que ya terminó ni borra el acta que una jurisdicción contestó antes del pedido.

La distinción parece obvia hasta el primer reclamo: el cliente asegura que canceló y el informe muestra multas. Las dos cosas pueden ser ciertas a la vez.

Un pedido con estado propio

La cancelación se dirige a una operación existente —el mismo recurso durable que aparece al responder 202 a una consulta larga—, no a la búsqueda original. Puede exponerse como DELETE /operations/{id} o como una acción explícita por POST.

RFC 9110 describe para DELETE tres respuestas según el momento: 202 si la acción probablemente se realice pero todavía no se ejecutó, 204 si ya se aplicó y no hay nada más que informar, y 200 cuando la respuesta incluye una representación con el estado resultante. La terna coincide con lo que ocurre: una operación con jurisdicciones en vuelo rara vez se detiene dentro de la misma llamada.

Lo honesto es aceptar el pedido, dejar la operación en cancellation_requested y publicar el estado terminal cancelled cuando el sistema confirme que no iniciará nada más. Un cliente que la sigue con polling y Retry-After deja de consultar recién ahí.

Repetir el pedido no debería cambiar nada. DELETE es idempotente según la misma especificación; una acción por POST no lo es, así que esa garantía queda de tu lado. Cancelar dos veces es normal, no un error.

La carrera contra el final

Entre que el operador decide cancelar y que el pedido llega, la consulta de esa patente puede haber terminado. Conviene devolver el estado real, no la etiqueta que el cliente esperaba: una operación completed no se reescribe como cancelled para que una pantalla quede prolija.

Cuando el estado actual no admite la solicitud, 409 es la respuesta que RFC 9110 prevé para un conflicto con el estado del recurso. El cuerpo puede seguir el formato de RFC 9457, con un type estable, un title legible y el estado actual como campo de extensión. El cliente necesita distinguir por programa “ya había terminado” de “no existe” o “no tenés permiso”, sin interpretar prosa.

Dejar de esperar no es cancelar

Un cliente que corta la conexión, agota su timeout o cierra la pestaña no canceló nada. El barrido de patentes sigue del otro lado y consume cuota, porque el reloj del cliente y el trabajo del servidor son cosas distintas. Tratar la desconexión como cancelación implícita es tentador y produce el problema inverso: consultas abortadas por una red inestable.

RFC 7240 separa las dos intenciones. La preferencia respond-async indica que el cliente prefiere una respuesta asincrónica; wait fija en segundos el tope de procesamiento que espera, y si el servidor lo va a exceder puede pasar a un manejo asincrónico. Son preferencias, no órdenes: el servidor puede ignorarlas y, cuando las aplica, informarlo con Preference-Applied. Ninguna detiene trabajo ya aceptado; para eso hace falta el pedido explícito.

Qué queda: resultados, cuota y retención

Una operación cancelada casi nunca está vacía. Lo que corresponde es un parcial —hallazgos, cobertura declarada y motivo de lo que falta—; presentarlo como “sin infracciones” convierte una decisión operativa en una afirmación falsa sobre el vehículo.

La cuota merece una regla escrita antes del primer reclamo: puede cobrarse el trabajo ejecutado, puede no cobrarse nada si la cancelación llegó antes de iniciar, o puede valer un criterio intermedio. Lo que no puede es descubrirse en la factura.

Cancelar tampoco es borrar. Quien lo pide suele querer las dos cosas —que se detenga y que no quede el acta encontrada—, y el endpoint sólo hace la primera. La retención de lo obtenido y su eliminación se rigen por la política de datos del servicio y necesitan su propio circuito.

Cómo se prueba y qué se registra

Una suite mínima intenta cancelar en cada estado —antes de empezar, en ejecución, después de un parcial y sobre una operación ya terminal— y verifica que la respuesta sea coherente. Sumá el pedido duplicado, el intento sobre una operación de otra empresa —que no debería confirmar siquiera su existencia— y la notificación posterior a la cancelación.

En el registro guardamos quién pidió la cancelación, cuándo, sobre qué estado y qué tareas quedaron sin iniciar. Sin eso, “lo canceló el usuario” es una versión sin respaldo cuando alguien pregunta por qué el informe de multas quedó corto.

Una cancelación útil no promete deshacer. Promete que el sistema deja de trabajar cuando se lo pedís y que lo hecho queda contado tal como fue.

Metodología

Alcance
Contrato de cancelación de una operación asincrónica de consulta de infracciones: estados que la admiten, respuestas, efectos sobre resultados y cuota. No cubre cómo interrumpe internamente cada proveedor una tarea ya enviada.
Unidad de análisis
Cada operación cancelable, identificada por su id opaco, y cada solicitud de cancelación recibida sobre ella.
Cobertura
Semántica de HTTP para DELETE, aceptación y conflicto, preferencias de manejo asincrónico y formato estándar de errores, vigentes al 29 de agosto de 2026.

Limitaciones

Fuentes

Preguntas frecuentes

¿Cancelar una consulta borra los resultados que ya se obtuvieron?

No. La cancelación detiene trabajo futuro y, cuando se puede, interrumpe el que está en curso; lo que las fuentes ya devolvieron se conserva y se informa como resultado parcial, con la cobertura efectiva declarada. Eliminar datos es otra decisión, con su propia política.

¿Cerrar la conexión o que venza el timeout del cliente cancela el trabajo?

No conviene asumirlo. El servidor puede seguir procesando una operación aceptada aunque el cliente deje de esperar. Para detenerla hace falta un pedido explícito sobre el recurso de la operación; una preferencia de espera declara un tope de procesamiento esperado, no una orden de cancelar.

¿Qué debería responder la API si la consulta terminó justo antes de la cancelación?

El estado real. Si la operación ya alcanzó un estado terminal, la respuesta puede rechazar la cancelación como un conflicto e informar el estado actual en un cuerpo de error tipificado. Reescribir una operación completada como cancelada esconde lo que efectivamente ocurrió.

¿Pedir la cancelación dos veces es un error?

No. Repetir el pedido sobre una operación ya cancelada debería devolver el mismo estado sin efectos nuevos. Con DELETE la idempotencia viene de la semántica del método; si la cancelación se expone como una acción POST, el servicio tiene que garantizarla por su cuenta.

Notas relacionadas