Cómo distinguir una tarea cancelada de una tarea ya iniciada

Una persona pulsa Cancelar justo cuando una exportación sale de la cola. La pantalla muestra «Cancelada», pero poco después aparece una descarga. El problema está en la promesa: la interfaz informó de un resultado antes de saber si el trabajo se había detenido.

En una aplicación empresarial, conviene acordar qué significa cancelar en cada etapa antes de aprobar el botón. La prueba ficticia siguiente utiliza una exportación llamada EXP-42 y registros desechables. Es una propuesta de aceptación, no un informe de trabajo realizado para un cliente.

Distinguir la solicitud del resultado

Que una solicitud de cancelación tenga éxito no siempre significa que la tarea se haya detenido. Por ejemplo, AWS Batch documenta que CancelJob puede responder con éxito sin cancelar una tarea que ya llegó a STARTING o RUNNING. AWS ofrece otra operación para terminar tareas en esos estados. Son reglas específicas de ese proveedor; revisa el contrato del servicio que realmente utiliza tu aplicación.

Define los estados que verá la persona usuaria con lenguaje claro. «Cancelación solicitada» indica que falta confirmación. «Cancelada antes de procesar» debe exigir evidencia de que el trabajo no continuó. «Detenida después de iniciarse» debe explicar cualquier resultado parcial. «Completada antes de la cancelación» debe conservar el acceso al resultado cuando la persona tenga permiso para verlo. Un resultado desconocido necesita un paso visible de verificación, no un mensaje de éxito inventado.

Decidir qué se puede detener todavía

Para EXP-42, pide al equipo que identifique el último punto en el que se puede impedir que la exportación quede disponible. Detener la preparación del archivo, evitar que se emita un enlace de descarga y eliminar un archivo existente son acciones diferentes. Escribe qué acción solicita el botón y quién puede realizarla.

La guía de Microsoft sobre solicitudes y respuestas asíncronas distingue la instrucción de cancelación de la actualización posterior del estado, una vez que el servidor la atiende, y propone considerar la reversión parcial o una acción compensatoria. Utiliza esa distinción para acordar el comportamiento. Detener una tarea no debe prometer implícitamente que se revertirá una notificación u otra acción externa ya realizada.

Ensayar ambos lados del punto límite

Utiliza un entorno de prueba con puntos de pausa controlables para que el resultado no dependa de pulsar rápidamente. Quien haga la prueba debe registrar el ID de la tarea, el punto de pausa, la respuesta a la cancelación, el estado final guardado y cualquier archivo o acción externa de prueba resultante.

• Todavía en espera: pausa EXP-42 antes de que empiece el proceso, solicita la cancelación, libera la pausa y comprueba que no se crea el resultado acordado.
• Procesamiento iniciado: pausa el proceso después de comenzar. Confirma si el comportamiento admitido consiste en detenerse de forma segura, terminar un paso acotado o rechazar la cancelación. Compara el resultado final con esa regla escrita.
• Ya completada: solicita la cancelación cuando el resultado ya existe. La pantalla no debe presentar el trabajo completado como si nunca se hubiera realizado.
• Respuesta perdida: interrumpe la conexión después de enviar la solicitud. Vuelve a abrir la misma tarea y recupera su estado actual; no crees otra exportación solo para que la pantalla parezca responder.
• Otra persona consultando: abre la misma tarea en una segunda sesión. Ambas vistas deben terminar mostrando el mismo resultado y conservar quién solicitó la cancelación.

Ofrecer una acción siguiente útil

Revisa los mensajes junto con los resultados de la prueba. «Cancelación solicitada; verificando EXP-42» es adecuado mientras falta confirmación. Si el procesamiento terminó primero, muestra el resultado real y explica si existe una acción de limpieza independiente que requiera autorización. Evita un botón genérico Reintentar que pueda repetir la acción empresarial cuando el resultado original sigue siendo incierto.

Acuerda un límite de espera y una persona responsable de atender las incidencias. Incluye la referencia de la tarea y el último estado confirmado en la vista de soporte. Un fallo al actualizar la consulta debe distinguirse de un fallo de cancelación confirmado.

Aprobar evidencia y mantener el contrato

El registro de aceptación debe relacionar cada escenario con el estado observado de la tarea, el mensaje visible y el resultado real. No apruebes la prueba solo por una respuesta HTTP exitosa o un botón deshabilitado. Repítela cuando cambien el proveedor de la cola, los pasos del proceso o sus efectos externos.

El alcance y el coste dependen del seguimiento de estados existente, los puntos de detención segura, las opciones del servicio externo y los requisitos de limpieza. Una hoja de decisiones breve con esas restricciones permite al equipo de desarrollo estimar un trabajo concreto.

Consulta con Dynelink las reglas de cancelación y las pruebas de aceptación de tu proceso empresarial.

Ilustración conceptual generada con IA; no es una captura de un cliente.