Como cancelar uma tarefa assíncrona sem esconder efeitos que já aconteceram

O que você vai levar deste guia

• Separe solicitação de cancelamento de cancelamento concluído.
• Defina pontos seguros de interrupção e destino de resultados parciais.
• Teste a disputa entre concluir e cancelar usando o estado confirmado.

Descreva o que o usuário espera interromper

Cancelar pode significar não começar, parar assim que possível, descartar o resultado ou desfazer mudanças. Essas intenções não são equivalentes. Comece observando a tarefa e perguntando qual consequência a pessoa pretende evitar. Uma geração de arquivo pode ser interrompida e ter o material temporário removido. Uma operação que envia documentos a terceiros pode já ter produzido efeitos que não desaparecem quando o trabalhador para. O botão precisa representar uma capacidade real.

No exemplo fictício da empresa Dossiê Técnico, uma pessoa solicita a montagem de um pacote com fotografias e relatórios de várias vistorias. Depois percebe que escolheu o período errado e clica em cancelar. O processamento pode estar consultando dados, baixando anexos ou finalizando o arquivo. A regra pretendida é interromper a preparação e não disponibilizar um pacote incompleto. Não há necessidade de apagar vistorias nem de alterar os documentos originais, porque a tarefa produz apenas um artefato derivado.

Registre o limite em linguagem de produto: cancelar interrompe a geração quando o trabalhador alcançar um ponto seguro e remove os arquivos temporários da operação; os dados de origem permanecem como estavam. Para uma tarefa diferente, escreva outro contrato. Não reutilize uma promessa genérica de cancelamento em todos os processos da plataforma se seus efeitos e capacidades de reversão são distintos.

Dê identidade ao trabalho e acompanhe seus estados

Uma tarefa longa precisa de uma referência estável que permita consultar seu estado depois que a solicitação inicial termina. A documentação da Microsoft sobre o padrão Asynchronous Request-Reply descreve a separação entre recebimento de uma solicitação e acompanhamento posterior de seu resultado. Essa organização é útil para o caso, mas o cancelamento exige decisões adicionais sobre estados e efeitos que o produto deve especificar.

Defina estados como aguardando, executando, cancelamento solicitado, cancelado, concluído e falhou, adaptando nomes ao fluxo. Evite tratar cancelamento solicitado como estado final. O trabalhador pode estar encerrando uma etapa ou aguardando a resposta de uma dependência. A interface deve mostrar que a interrupção está em andamento e atualizar quando houver confirmação. O histórico precisa registrar os instantes relevantes para explicar uma demora na parada.

Estabeleça transições válidas. Uma tarefa concluída não deve voltar para executando por um pedido atrasado, e uma tarefa cancelada não deve publicar resultado depois. Quando for permitido refazer, crie uma nova execução relacionada ou uma tentativa claramente identificada, conforme o modelo. Misturar recomeço e continuação no mesmo estado dificulta saber quais arquivos e registros pertencem a cada trabalho, especialmente durante limpeza e suporte.

Registre a intenção antes de tentar interromper o trabalhador

O pedido de cancelamento deve ser persistido de forma que sobreviva a reinícios. Enviar apenas um sinal transitório a um processo pode falhar se ele estiver indisponível ou se outro trabalhador assumir depois. A tarefa precisa carregar a intenção atual, e o executor deve consultá-la nos momentos definidos. Registre quem pediu, quando e em qual contexto autorizado, sem transformar essa informação em texto livre que determine o comportamento técnico.

Verifique a autorização para cancelar aquela tarefa. Uma pessoa pode ter direito de iniciar trabalhos próprios e não de interromper os de toda a empresa. O identificador recebido pela API não comprova esse direito. Também considere tarefas compartilhadas: se várias pessoas dependem do mesmo resultado, a política pode exigir um papel específico ou separar abandonar o acompanhamento de cancelar a execução. Essa distinção precisa ser definida antes de oferecer um botão único.

Na Dossiê Técnico fictícia, o pedido repetido de cancelamento deve devolver o estado atual sem criar novas operações de limpeza. Se a tarefa ainda está na fila, pode ser marcada para não iniciar. Se já executa, a intenção permanece até o trabalhador confirmar a interrupção. Se já terminou, a resposta deve informar conclusão, podendo oferecer uma operação diferente para excluir o pacote quando isso fizer parte do produto.

Escolha pontos de parada que preservem a integridade

O trabalhador precisa verificar o cancelamento entre unidades de trabalho adequadas. Na montagem do pacote, pode conferir antes de consultar o próximo grupo de vistorias, antes de baixar outro anexo e antes de publicar o arquivo final. Verificar a cada operação mínima pode ter custo desnecessário; verificar apenas ao final torna o botão pouco útil. Meça a duração das etapas e escolha uma frequência compatível com a expectativa de resposta.

Considere chamadas que não podem ser interrompidas imediatamente. Uma biblioteca ou serviço externo pode continuar processando depois de o cliente deixar de esperar. O sistema deve conhecer esse limite e impedir que o retorno tardio publique um resultado de tarefa já cancelada. Uma interrupção local de espera não prova cancelamento remoto. Se o fornecedor oferece uma operação de cancelamento, trate sua confirmação de acordo com o contrato específico, sem presumir que o envio do pedido encerrou tudo.

Não abandone uma transação ou um arquivo em estado indefinido. Defina como fechar recursos, reverter alterações ainda não confirmadas e marcar o destino do material parcial. Para tarefas que atualizam registros por partes, talvez seja necessário terminar a unidade atual e parar antes da próxima. Nesse caso, a interface precisa informar quantas partes foram concluídas e o que permaneceu. O ponto seguro é uma decisão de integridade e de experiência, não apenas uma chamada para interromper uma thread.

Resolva a disputa entre concluir e cancelar

Há uma janela em que o trabalhador está prestes a marcar sucesso enquanto chega o cancelamento. Defina a ordem de confirmação no armazenamento. A transição final deve ser condicional ao estado apropriado, de forma que não existam duas confirmações contraditórias. Uma leitura seguida de escrita sem proteção pode permitir que cada processo anuncie um resultado diferente. Teste essa disputa deliberadamente, em vez de confiar que o intervalo é curto demais para acontecer.

No exemplo fictício, antes de disponibilizar o pacote, o trabalhador verifica e confirma de forma coordenada que a tarefa continua apta à conclusão. Se o cancelamento venceu a disputa, o arquivo é tratado como temporário e não aparece para download. Se a conclusão já foi confirmada, o pedido de cancelamento recebe esse estado e a interface explica que o pacote foi finalizado. A política exata pode variar, mas precisa ter um vencedor observável e consistente.

Separe armazenamento físico de publicação lógica. Um arquivo pode estar gravado sem estar disponível ao usuário. Essa separação permite validar e decidir a conclusão antes de expor o resultado. Não use a mera existência de um objeto no armazenamento como prova de tarefa concluída. A disponibilização deve depender do estado confirmado e das permissões, inclusive quando alguém tenta acessar uma referência obtida durante a preparação.

Classifique e limpe resultados parciais

Liste os artefatos produzidos por etapa: arquivos temporários, referências de download, registros auxiliares e mensagens de progresso. Determine quais são descartáveis e quais precisam permanecer como evidência. A limpeza deve usar referências ligadas à tarefa, não padrões amplos de nome que possam alcançar trabalho de outra execução. Uma interrupção não justifica uma remoção indiscriminada. O escopo precisa ser verificável e compatível com a organização dos recursos.

Planeje falha da própria limpeza. A tarefa pode estar cancelada operacionalmente enquanto ainda existe um arquivo temporário aguardando remoção. Registre essa pendência de manutenção sem apresentar a execução como ativa novamente. Defina prazo e monitoramento para evitar acúmulo. Se o artefato contém dados sensíveis, sua permanência precisa ser tratada conforme as regras do sistema, com acesso restrito mesmo durante a espera pela limpeza.

Para operações com efeitos externos, documente compensação separadamente. Parar novos envios não recolhe documentos já entregues. Uma tarefa de cancelamento pode precisar informar o que foi confirmado antes da interrupção e oferecer uma ação posterior autorizada. A Tironi Tech pode desenvolver essa trilha e os mecanismos de limpeza para que o estado apresentado corresponda aos efeitos reais, evitando que a palavra cancelado seja interpretada como um apagamento que nunca ocorreu.

Desenhe a experiência durante a espera pela parada

Depois do pedido, desabilite ações incompatíveis e apresente o estado de interrupção com clareza. Não apague a tarefa da lista imediatamente, porque a pessoa perde a capacidade de conferir o resultado. Permita sair da tela e voltar. Se houver uma etapa longa que não pode ser interrompida, explique a limitação de forma breve e baseada no comportamento real. Evite cronômetros fictícios que terminam antes do trabalhador.

Mostre resultados parciais quando forem relevantes à decisão. No caso do pacote, pode bastar dizer que nenhum arquivo foi disponibilizado. Em uma rotina de atualização por registros, é necessário informar quantos foram confirmados e quais ficaram pendentes. Esses números devem vir do estado processado, não de uma estimativa de progresso da interface. A pessoa precisa saber se pode iniciar outra tarefa ou se primeiro deve revisar o que já aconteceu.

Considere falhas de conexão do navegador. O clique pode ter chegado ao servidor mesmo que a resposta tenha se perdido. Ao reconectar, consulte o estado da mesma tarefa em vez de assumir que o pedido falhou e criar outra execução. Uma operação de cancelamento repetível ajuda nesse cenário, mas a interface ainda precisa relacionar o resultado ao identificador correto. O usuário não deve ter de adivinhar se o sistema recebeu a intenção.

Teste interrupções em todas as etapas relevantes

Monte testes para cancelar na fila, durante leitura, durante geração, antes da publicação e depois da conclusão. Inclua reinício do trabalhador após o pedido, repetição da solicitação e falha na limpeza. Verifique estado final, disponibilidade de resultado e recursos remanescentes. O teste deve comprovar que a tarefa não publica depois de confirmada como cancelada, além de assegurar que uma conclusão já confirmada não é apresentada como interrompida.

Execute um teste de concorrência com barreiras controladas para aproximar cancelamento e conclusão. Observe também o tempo até a parada em etapas representativas. Se a expectativa da interface é incompatível com o comportamento medido, ajuste o processamento ou a comunicação. Não declare cancelamento instantâneo porque o endpoint responde rápido; o tempo relevante é até cessar o trabalho e tratar os efeitos conforme o contrato.

Finalize com um procedimento de suporte: localizar tarefa, conferir pedido, identificar etapa atual e verificar pendências de limpeza. Registre métricas de tempo de interrupção e ocorrências que permanecem em cancelamento solicitado por mais que o esperado. Uma tarefa longa bem controlada oferece continuidade e interrupção com estados confiáveis. O objetivo é que a pessoa possa mudar de ideia sem perder visibilidade sobre o que o sistema já fez e o que ainda está encerrando.

Perguntas frequentes

Fechar a aba cancela a tarefa?

Somente se esse comportamento foi explicitamente implementado. Trabalhos em segundo plano normalmente continuam independentes da aba, e a interface deve permitir consultar seu estado depois.

Cancelar significa desfazer tudo?

Não. Interrupção e reversão são operações diferentes. Defina quais resultados são descartáveis, quais já foram confirmados e se existe uma compensação apropriada.

E se a tarefa terminar junto com o pedido de cancelamento?

O servidor precisa resolver essa disputa e devolver o estado real. A interface não deve anunciar cancelamento antes de receber a confirmação correspondente.

Dê controle às tarefas longas do seu sistema

A Tironi Tech pode desenvolver processamento assíncrono com acompanhamento, cancelamento e tratamento explícito de resultados parciais.

Artigos relacionados

• Como processar uma alteração em lote com retomada e conferência por item
• Software para automatizar processos: pronto, integrado ou sob medida?
• Como modernizar um sistema legado substituindo um módulo de cada vez

Fontes consultadas

• Microsoft — Asynchronous Request-Reply pattern