DocsExecutarContinuar automaticamente

Interrupções inesperadas e retomar automaticamente

O que acontece se um workflow é interrompido a meio caminho? Configure os passos de recuperação e idempotente para retomar do ponto de interrupção sem repetir efeitos colaterais externos.

"O que fazer se a execução não for concluída de uma só vez" é uma pergunta que o workflow em nível de produção deve responder.

Padrão: pausa segura — Marque a execução como INTERROMPIDA e espere até vê-la claramente antes de "tentar novamente" manualmente a partir de uma determinada etapa intermediária.
Opcional: continuar executando automaticamente — Depois de declarar explicitamente "este workflow pode continuar + quais etapas são idempotentes", a plataforma continuará automaticamente a partir do ponto de interrupção.

O que significa interrupção?

Duas categorias:

Lado da plataforma – o serviço é reiniciado, as instâncias são substituídas, o host falha.
Do seu lado - você "cancela" ativamente uma execução (para em CANCELADO, não INTERROMPIDO).

Somente a categoria anterior entrará no processo de “continuação automática”, e a execução de CANCELLED não será executada automaticamente.

Comportamento padrão: pausa segura

Quando ocorre uma interrupção no lado da plataforma, a plataforma:

Marcar o status de execução como INTERROMPIDO;
Mantenha os resultados, produtos e registros de todas as etapas concluídas;
Você recebe uma notificação no local (e-mail/Slack também será configurado de acordo com sua notificação);
Ao acessar a página de detalhes da execução, você pode “tentar novamente a partir da etapa com falha” – a plataforma reutiliza os resultados da etapa anterior.

Este padrão está disponível para todos os workflows e não requer configuração.

O workflow contém efeitos colaterais externos (envio de e-mails/dedução de dinheiro/modificação de banco de dados)
Quando a produção ainda não tem certeza “se é seguro reiniciar e continuar em execução”

Opcional: continuar executando automaticamente

Se o seu workflow for um pipeline de dados puro (API somente leitura + geração de relatórios), você poderá ativar a continuação automática - após ocorrer uma interrupção, a plataforma continuará funcionando automaticamente a partir do ponto de interrupção, sem que você precise clicar manualmente.

Ativação de dois níveis ativada

Para que a continuação automática tenha efeito, você precisa declarar ambas as camadas em YAML:

nível de workflow: Declaração recovery.autoResumeOnRestart: true
nível de passo: Instruções passo a passo para repetições seguras idempotent: true

Exemplo completo

yaml

name: daily-asa-digest
version: "1.0.0"

recovery:
  autoResumeOnRestart: true
  policy: RESUME_FROM_LAST_INCOMPLETE
  maxAutoResumeAttempts: 3

steps:
  - id: fetch_asa_data
    type: sub_workflow
    module: dingyue-module-asa-fetch
    idempotent: true           # 只读拉取，可重跑

  - id: build_excel
    type: sub_workflow
    module: dingyue-module-excel-report
    idempotent: true           # 生成文件到产物目录，可重跑

  - id: notify_team
    type: sub_workflow
    module: dingyue-module-slack-deliver
    # 不写 idempotent —— 默认 false，发消息不可重跑

Três políticas de recuperação

policy	significado	Adequado para a cena
`ABORT`	Não restaurar automaticamente equivale a retornar ao comportamento padrão.	fase de testes
`RESUME_FROM_LAST_INCOMPLETE`	Padrão.	Pipelines de dados, agregações de API somente leitura, computação pura
`RESUME_FROM_START`	Execute novamente todo o workflow do zero	Cenários em que as fontes de dados podem mudar durante interrupções e precisam ser atualizadas

idempotent Como marcar

O padrão ouro para determinar se uma etapa é idempotente:

“Se a mesma entrada for executada duas vezes, haverá algum efeito colateral?”

Se você puder (enviar mensagens externas, cobrar dinheiro, escrever pedidos), não adicione idempotente.

Propriedades da etapa	`idempotent`
Consulta de API somente leitura (relatório pull, aplicativo de lista)	✓ true
Cálculo puro/conversão de dados	✓ true
Gere Markdown/Excel para o diretório de produtos	✓ true(Produtos antigos serão apagados antes de serem executados novamente)
Inferência LLM (ferramenta sem efeitos colaterais)	✓ true(Os tokens serão recalculados, mas semanticamente seguros)
Enviar email / Telegram / Slack / Feishu	✗ false
Gravar no banco de dados externo/Alterar lance do anúncio/Fazer pedido/Débito	✗ false
Chamadas de saída de webhook	✗ false(A menos que o outro endpoint remova explicitamente as duplicatas)
manual_approval	✗ false(Continuar a execução fará um ping novamente no aprovador, o que é uma experiência ruim)

O valor padrão é falso – segurança em primeiro lugar

Se idempotente não for escrito, o padrão é falso.

Várias situações que não ocorrerão durante a continuação automática

Mesmo se você configurar a recuperação, as seguintes execuções ainda não continuarão sendo executadas automaticamente:

A origem do gatilho é um Webhook - a carga útil do Webhook pode ser no máximo uma vez e a plataforma não sabe se o upstream tentará novamente.
A fonte do gatilho é o Agendador - o agendador será acionado novamente na próxima rodada do cron.
Atualmente parado em manual_approval - aguardar aprovação significa que está originalmente bloqueado.
O arquivo de definição de workflow foi modificado durante a interrupção – a plataforma detectou uma incompatibilidade de hash e não tem certeza se a nova versão é compatível.

Manual "Tentar novamente a partir de uma etapa" (disponível a qualquer momento)

Independentemente de o workflow estar configurado com recuperação ou não, a página de detalhes da execução sempre fornece um botão "Tentar novamente da etapa com falha":

Abra uma execução INTERROMPIDA/FALHA;
Clique em "Tentar novamente nesta etapa" ao lado da etapa com falha/interrompida;
O resultado da etapa anteriormente CONCLUÍDA será reaproveitado;

Mesmo que a etapa não seja idempotente, você pode tentar novamente manualmente - porque é quando você, como ser humano, decide conscientemente que "vale a pena executá-la novamente".

Continuar executando o limite

Evita que o sistema reinicie a mesma execução em um “loop infinito”: cada execução continuará automaticamente até 3 vezes.

Auditoria

Os eventos de auditoria serão registrados sempre que a continuação automática for realizada:

execution.auto_resume — Continuou em execução com sucesso
execution.auto_resume.skipped — De acordo com as regras, você não deve continuar correndo, com razão

O administrador pode filtrar e visualizar os logs de auditoria por esses dois event_types.

Sugestões práticas

Pipeline de dados puro (ASA diário, resumo RSS): recuperação total + idempotente, tenha certeza de que continuará funcionando automaticamente.
Se houver efeitos colaterais externos (deduções, envio de mensagens, realização de pedidos): não abra o currículo automático.
Adicione manual_approval antes das principais etapas de efeitos colaterais - a aprovação em si é um "ponto de bloqueio natural" para execução descontínua.

Próximo passo

Monitoramento e registro de execução — Como visualizar a execução no estado INTERROMPIDO
Melhores Práticas — Sugestões abrangentes para anotação/divisão/modularização idempotente