Um timeout do cron não prova que sua ação no OpenClaw falhou

Se um job cron expirar após enviar uma mensagem, publicar conteúdo ou solicitar uma implantação, o OpenClaw sabe que a execução falhou. Pode não saber se o provedor aceitou a ação.

Essa distinção importa porque a documentação atual de tarefas agendadas do OpenClaw diz que falhas únicas transitórias podem ser repetidas, enquanto falhas recorrentes usam backoff exponencial. Repetir a ação sem verificar o provedor pode criar duplicatas.

Trate um timeout ambíguo como desconhecido, não como falho:

preparado -> tentado -> confirmado -> confirmado_ausente -> desconhecido -> reconciliar

Antes da gravação, preserve a tarefa, o efeito pretendido, o alvo, o hash do payload e a chave de operação. Use uma chave de idempotência do provedor quando suportado.

Após um timeout, consulte o provedor autoritativo usando seu recibo, chave de operação ou identidade natural do recurso. Repita somente após confirmar que o efeito está ausente. Se a ausência não puder ser comprovada, pare para revisão.

Publicação, implantação, pagamento, exclusão e ações semelhantes devem manter seus limites de aprovação existentes.

A documentação de auditoria do OpenClaw já trata unknown como um estado explícito de não-sucesso quando nenhum resultado terminal autoritativo está disponível. Esse é o modelo operacional correto para gravações externas ambíguas.

Um teste útil é um endpoint sandbox que aceita uma gravação, mas retém a resposta. O fluxo de trabalho deve registrar unknown, evitar uma segunda gravação, reconciliar o primeiro objeto e então classificá-lo como confirmado.