Votre historique d'automatisation affiche une exécution réussie et un ensemble de résultats. Facebook affiche deux publications.

Cette preuve exclut certaines explications simples, mais elle ne prouve pas quel système a dupliqué l’écriture. N'exécutez plus l'automatisation. Conservez les originaux des deux fournisseurs et créez une ligne de preuve pour chaque écriture susceptible d'avoir atteint Facebook.

Cette liste de contrôle couvre le cas spécifique où un flux de travail Airtable, Make, n8n ou personnalisé semble s'exécuter une fois tandis qu'une page Facebook reçoit des publications en double.

La réponse courte

Avant de changer de scénario, enregistrez :

  1. l'ID d'exécution de l'automatisation et l'heure exacte de début/fin
  2. chaque paquet d'entrée ou ID d'enregistrement source
  3. Historique des nouvelles tentatives, des exécutions incomplètes et des délais d'attente
  4. chaque identifiant de publication Facebook et lien permanent
  5. l'horodatage public et le contenu rendu de chaque publication

Si les deux publications Facebook ont ​​des ID de fournisseur différents, il y a eu deux créations côté fournisseur même si l'interface utilisateur d'automatisation résume le travail en une seule exécution. La question restante est de savoir d'où provient la deuxième création : un autre déclencheur, une nouvelle tentative automatique, une récupération après expiration d'un délai, une duplication côté fournisseur ou un client distinct utilisant le même enregistrement source.

N'étiquetez pas la cause jusqu'à ce que les preuves distinguent ces chemins.

1. Préservez d’abord les deux originaux publics

Ouvrez les deux publications Facebook avant de supprimer ou de modifier l'une ou l'autre. Pour chaque publication, capturez :

  • Identité de la page
  • ID de poste du fournisseur
  • lien permanent
  • horodatage publié
  • légende exacte et média
  • tout auteur visible ou attribution de publication

Comparez le texte et l'empreinte digitale du média. Deux légendes identiques ne prouvent pas que la même requête a été rejouée ; deux clients indépendants peuvent envoyer le même enregistrement source. Deux ID de fournisseur différents prouvent que le fournisseur a accepté deux créations.

Si un seul lien permanent est disponible et que le deuxième message est toujours visible, conservez une capture d'écran et l'horodatage public pendant que vous enquêtez. Marquez l’ID manquant comme unknown.

2. Séparez l'exécution d'un scénario de l'écriture d'un fournisseur

Une exécution d'automatisation verte signifie que l'orchestration est terminée selon les règles de cette plateforme. Cela ne signifie pas nécessairement qu’une écriture externe a eu lieu.

Créez des documents indiquant que les échecs de connexion, de limite de débit et de délai d'attente peuvent être réessayés en raison d'exécutions incomplètes et d'une interruption exponentielle. Sa documentation indique également que les actions dans les applications externes non transactionnelles ne peuvent pas être annulées. La création d'un fournisseur peut donc réussir même lorsqu'une étape ultérieure du client expire ou perd la réponse.

Vérifiez-les séparément :

Couche Preuves à recueillir Ce que cela peut prouver
Déclencheur heure de planification/webhook et ID de déclencheur combien de courses ont été lancées
Source ID d'enregistrement Airtable et nombre de paquets d'entrée combien d'enregistrements sont entrés dans le flux
Créer un module fonctionnement du module, heure de début/fin, sortie brute combien d'appels du fournisseur la plateforme a-t-elle enregistrés
Système de nouvelle tentative exécutions incomplètes, nouvelles tentatives automatiques, historique des interruptions si un appel échoué ou ambigu a été réexécuté
Facebook chaque identifiant de publication et lien permanent combien d'objets de fournisseur public existent

Ne réduisez pas ces cinq lignes en « l'exécution a réussi ».

3. Recherchez les seconds déclencheurs cachés

Avant de blâmer Facebook, éliminez les causes que vous pouvez contrôler :

  • un autre scénario planifié utilisant la même Page
  • un webhook instantané plus une recherche horaire
  • un deuxième espace de travail, environnement ou ancien scénario
  • deux enregistrements sources avec le même contenu
  • une publication manuelle réalisée depuis la Page ou la Business Suite
  • une fenêtre d'interrogation qui sélectionne à nouveau un enregistrement avant que sa mise à jour de statut ne soit visible

Utilisez des identifiants stables, pas seulement des horodatages. Enregistrez l'ID du scénario d'automatisation, l'ID de l'enregistrement source, l'empreinte digitale du contenu et l'ID de la page de destination dans la même ligne.

Si deux flux de travail partagent une table source, ajoutez une revendication ou un verrou spécifique à la destination avant la création du fournisseur. Un tampon temporel à lui seul ne constitue pas une garantie d’idempotence.

4. Traitez une réponse lente comme ambiguë

Un module Facebook de longue durée constitue une preuve importante, mais il n'identifie pas la cause en soi.

Si le fournisseur a accepté la publication et que le client a expiré avant de recevoir la réponse, une nouvelle tentative automatique peut créer une autre publication à moins que l'intégration ne rapproche le premier résultat. Si le module a renvoyé un identifiant de fournisseur alors que deux publications existent, conservez l'identifiant de publication sans correspondance et demandez quel acteur l'a créé.

La règle de sécurité est la suivante :

Un délai d'attente ou une réponse perdue est unknown, et non failed, jusqu'à ce que la destination soit vérifiée.

Suspendez la récupération automatique pour cette destination lorsqu'un identifiant de fournisseur ou une publication publique correspondante existe déjà.

5. Construisez un registre de preuves à deux postes

Utilisez une ligne par objet fournisseur :

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

Pour deux publications Facebook, le registre doit contenir deux lignes même si la plateforme d'automatisation expose une seule exécution. Les champs sans correspondance montrent où l'enquête a besoin de preuves plus solides.

6. Ajouter une porte de récupération à l'échelle de la destination

Avant une création ou une nouvelle tentative, vérifiez l'enregistrement existant pour cette page :

  1. Existe-t-il déjà un identifiant de poste de fournisseur ?
  2. Y a-t-il un lien permanent stocké ?
  3. La page publique contient-elle une empreinte digitale de contenu correspondante dans la fenêtre de temps prévue ?
  4. Une exécution incomplète est-elle toujours éligible pour réessayer le module de création ?

Lorsque le résultat est ambigu, déplacez l'élément vers un rapprochement manuel au lieu de le créer à nouveau. Lorsqu'un lot multicanal réussit partiellement, réessayez uniquement la destination non résolue après avoir vérifié l'état de son propre fournisseur.

Cette porte ne garantit pas que chaque fournisseur expose une clé d'idempotence. Cela empêche votre logique de récupération de traiter la confirmation client manquante comme une preuve que rien n'a été créé.

Un véritable avertissement de réussite partielle provenant d'un autre réseau

Dans un incident ANKK Threads distinct, une racine planifiée a été publiée et l’étape de réponse a rencontré un résultat non disponible pour le fournisseur. La récupération automatique a produit deux réponses publiques identiques même si l'opérateur n'a effectué aucune nouvelle tentative manuelle. Les originaux du fournisseur, le contenu stable et les ID de travail ont été conservés pour l'enquête sur le produit.

Cet incident Threads ne prouve pas la cause d'un doublon sur Facebook. Cela démontre la limite générale de l'échec : une fois qu'un segment peut avoir atteint le fournisseur, la récupération nécessite une réconciliation du fournisseur au niveau de ce segment plutôt qu'une relecture aveugle de l'ensemble de l'opération.

Sources et prochaines étapes

J'exploite ANKK. ANKK n'inclut pas d'écrivain IA intégré. Il connecte le contenu préparé par des personnes, des outils d'IA externes ou des scripts à la planification sociale, aux états au niveau des canaux et à la vérification d'origine du fournisseur.

Consultez le flux de travail du développeur ANKK