Seu histórico de automação mostra uma execução bem-sucedida e um pacote de saída. O Facebook mostra duas postagens.

Essa evidência exclui algumas explicações simples, mas não prova qual sistema duplicou a gravação. Não execute a automação novamente. Preserve os originais dos dois fornecedores e crie uma linha de evidência para cada gravação que possa ter chegado ao Facebook.

Esta lista de verificação cobre o caso específico em que um fluxo de trabalho Airtable, Make, n8n ou personalizado parece ser executado uma vez enquanto uma página do Facebook recebe postagens duplicadas.

A resposta curta

Antes de alterar o cenário, registre:

  1. o ID de execução da automação e a hora exata de início/término
  2. cada pacote de entrada ou ID de registro de origem
  3. histórico de novas tentativas, execução incompleta e tempo limite
  4. cada ID de postagem e link permanente do Facebook
  5. o carimbo de data/hora público e o conteúdo renderizado de cada postagem

Se as duas postagens do Facebook tiverem IDs de provedor diferentes, houve duas criações no lado do provedor, mesmo que a UI de automação resumisse o trabalho como uma única execução. A questão restante é onde a segunda criação se originou: outro gatilho, uma nova tentativa automática, uma recuperação de tempo limite, uma duplicata do lado do provedor ou um cliente separado usando o mesmo registro de origem.

Não rotule a causa até que a evidência distinga esses caminhos.

1. Preserve primeiro os dois originais públicos

Abra ambas as postagens do Facebook antes de excluir ou editar qualquer uma delas. Para cada postagem, capture:

  • Identidade da página
  • ID da postagem do provedor
  • link permanente
  • carimbo de data/hora publicado
  • legenda exata e mídia
  • qualquer autor visível ou atribuição de publicação

Compare a impressão digital do texto e da mídia. Duas legendas idênticas não provam que a mesma solicitação foi reproduzida; dois clientes independentes podem enviar o mesmo registro de origem. Dois IDs de provedor diferentes provam que o provedor aceitou duas criações.

Se apenas um link permanente estiver disponível e a segunda postagem ainda estiver visível, preserve uma captura de tela e o carimbo de data/hora público enquanto você investiga. Marque o ID ausente como unknown.

2. Separar um cenário executado de uma gravação de provedor

Uma execução de automação verde significa a orquestração concluída de acordo com as regras dessa plataforma. Isso não significa necessariamente que ocorreu uma gravação externa.

Faça documentos em que falhas de conexão, limite de taxa e tempo limite possam ser repetidas por meio de execuções incompletas e espera exponencial. Sua documentação também observa que as ações em aplicativos externos não transacionais não podem ser revertidas. A criação de um provedor pode, portanto, ser bem-sucedida mesmo quando uma etapa posterior do cliente expira ou perde a resposta.

Verifique-os separadamente:

Camada Provas a recolher O que isso pode provar
Gatilho horário do agendamento/webhook e ID do gatilho quantas execuções foram iniciadas
Fonte ID de registro Airtable e contagem de pacotes de entrada quantos registros entraram no fluxo
Criar módulo operação do módulo, horário de início/término, saída bruta quantas chamadas de provedor a plataforma registrou
Sistema de nova tentativa execuções incompletas, novas tentativas automáticas, histórico de espera se uma chamada com falha ou ambígua foi executada novamente
Facebook cada ID de postagem e link permanente quantos objetos de provedor público existem

Não reduza essas cinco linhas em “execução bem-sucedida”.

3. Verifique se há segundos gatilhos ocultos

Antes de culpar o Facebook, elimine as causas que você pode controlar:

  • outro cenário agendado usando a mesma página
  • um webhook instantâneo e uma pesquisa de hora em hora
  • um segundo espaço de trabalho, ambiente ou cenário antigo
  • dois registros de origem com o mesmo conteúdo
  • uma postagem manual feita na página ou no Business Suite
  • uma janela de votação que seleciona um registro novamente antes que sua atualização de status fique visível

Use identificadores estáveis, não apenas carimbos de data/hora. Registre o ID do cenário de automação, o ID do registro de origem, a impressão digital do conteúdo e o ID da página de destino na mesma linha.

Se dois fluxos de trabalho compartilharem uma tabela de origem, adicione uma declaração ou bloqueio específico do destino antes da criação do provedor. Um buffer de tempo por si só não é uma garantia de idempotência.

4. Trate uma resposta lenta como ambígua

Um módulo do Facebook de longa duração é uma evidência importante, mas não identifica a causa por si só.

Se o provedor aceitou a postagem e o cliente atingiu o tempo limite antes de receber a resposta, uma nova tentativa automática poderá criar outra postagem, a menos que a integração reconcilie o primeiro resultado. Se o módulo retornou um ID de provedor enquanto existem duas postagens, preserve o ID da postagem sem correspondência e pergunte qual ator o criou.

A regra segura é:

Um tempo limite ou resposta perdida é unknown, não failed, até que o destino seja verificado.

Pause a recuperação automática para esse destino quando já existir qualquer ID de provedor ou postagem pública correspondente.

5. Crie um livro de evidências de duas postagens

Use uma linha por objeto provedor:

destination_page_id:
source_record_id:
automation_execution_id:
create_module_operation_id:
retry_or_incomplete_execution_id:
provider_post_id:
provider_permalink:
provider_timestamp:
content_fingerprint:
public_outcome:
observed_in_automation_output: yes | no | unknown

Para duas postagens no Facebook, o livro-razão deve conter duas linhas, mesmo que a plataforma de automação exponha uma execução. Os campos sem correspondência mostram onde a investigação precisa de evidências mais fortes.

6. Adicione um portão de recuperação com escopo de destino

Antes de criar ou tentar novamente, verifique o registro existente dessa página:

  1. Já existe um ID de postagem do provedor?
  2. Existe um link permanente armazenado?
  3. A página pública contém uma impressão digital de conteúdo correspondente no intervalo de tempo esperado?
  4. Uma execução incompleta ainda é elegível para tentar novamente o módulo de criação?

Quando o resultado for ambíguo, mova o item para reconciliação manual em vez de criar novamente. Quando um lote multicanal for parcialmente bem-sucedido, tente novamente apenas o destino não resolvido após verificar o estado do seu próprio provedor.

Esta porta não garante que todo provedor exponha uma chave de idempotência. Isso evita que sua lógica de recuperação trate a confirmação perdida do cliente como prova de que nada foi criado.

Um verdadeiro aviso de sucesso parcial de outra rede

Em um incidente separado do ANKK Threads, uma raiz agendada foi publicada e a etapa de resposta encontrou um resultado de provedor indisponível. A recuperação automática produziu duas respostas públicas idênticas, embora o operador não tenha feito nenhuma nova tentativa manual. Os originais do fornecedor, o conteúdo estável e os job IDs foram preservados para a investigação do produto.

Esse incidente do Threads não prova a causa de uma duplicata do Facebook. Ele demonstra o limite geral da falha: uma vez que qualquer segmento tenha alcançado o provedor, a recuperação precisa da reconciliação do fornecedor naquele segmento, em vez de uma repetição cega de toda a operação.

Fontes e próximas etapas

Eu opero ANKK. ANKK não inclui um gravador de IA integrado. Ele conecta conteúdo preparado por pessoas, ferramentas externas de IA ou scripts à programação social, estados em nível de canal e verificação provider original.

Revise o fluxo de trabalho do desenvolvedor ANKK