自動化履歴には、1 つの成功した実行と 1 つの出力バンドルが表示されます。 Facebook には 2 つの投稿が表示されます。

この証拠はいくつかの単純な説明を除外しますが、どのシステムが書き込みを複製したかを証明するものではありません。自動化を再度実行しないでください。両方のプロバイダーのオリジナルを保存し、Facebook に到達した可能性のある書き込みごとに 1 つの証拠行を作成します。

このチェックリストでは、Facebook ページが重複した投稿を受信して​​いる間に Airtable、Make、n8n、またはカスタム ワークフローが 1 回実行されるように見える特定のケースについて説明します。

短い答え

シナリオを変更する前に、次のことを記録してください。

  1. オートメーション実行 ID と正確な開始/終了時刻
  2. すべての入力バンドルまたはソースレコード ID
  3. リトライ、未完了実行、タイムアウト履歴
  4. すべての Facebook 投稿 ID とパーマリンク
  5. 各投稿の公開タイムスタンプとレンダリングされたコンテンツ

2 つの Facebook 投稿のプロバイダー ID が異なる場合、自動化 UI が作業を 1 つの実行として要約する場合でも、プロバイダー側​​で 2 つの作成が行われたことになります。残りの疑問は、2 番目の作成がどこから行われたのかです。別のトリガー、自動再試行、タイムアウト回復、プロバイダー側​​の複製、または同じソース レコードを使用する別のクライアントです。

証拠がそれらの経路を区別するまで、原因をラベル付けしないでください。

1. まず両方の公開オリジナルを保存します

どちらかの Facebook 投稿を削除または編集する前に、両方の Facebook 投稿を開いてください。投稿ごとに、以下をキャプチャします。

  • ページのアイデンティティ
  • プロバイダー投稿ID
  • パーマリンク
  • 公開されたタイムスタンプ
  • 正確なキャプションとメディア
  • 表示される著者または投稿の帰属

テキストとメディアのフィンガープリントを比較します。 2 つの同一のキャプションは、同じリクエストがリプレイされたことを証明するものではありません。 2 つの独立したクライアントが同じソース レコードを送信できます。 2 つの異なるプロバイダー ID は、プロバイダーが 2 つの作成を受け入れたことを証明します。

利用可能なパーマリンクが 1 つだけで、2 番目の投稿がまだ表示されている場合は、調査中にスクリーンショットと公開タイムスタンプを保存してください。欠落している ID を unknown としてマークします。

2. シナリオの実行とプロバイダーの書き込みを分離する

グリーン オートメーションの実行とは、そのプラットフォームのルールに従ってオーケストレーションが完了したことを意味します。必ずしも 1 回の外部書き込みが発生したことを意味するわけではありません。

接続、レート制限、およびタイムアウトの失敗が不完全な実行と指数バックオフによって再試行できることを文書に作成します。そのドキュメントには、非トランザクション外部アプリのアクションはロールバックできないことも記載されています。したがって、後のクライアント ステップがタイムアウトになったり、応答が失われたりしても、プロバイダーの作成は成功する可能性があります。

これらを個別に確認してください。

レイヤー 収集する証拠 それが証明できること
トリガー スケジュール/Webhook 時間とトリガー ID 何回の実行が開始されましたか
出典 Airtable レコード ID と入力バンドル数 フローに入ったレコードの数
モジュールの作成 モジュールの操作、開始/終了時刻、生の出力 プラットフォームが記録したプロバイダー コールの数
リトライシステム 不完全な実行、自動再試行、バックオフ履歴 失敗した呼び出しまたはあいまいな呼び出しが再度実行されたかどうか
フェイスブック すべての投稿 ID とパーマリンク パブリック プロバイダー オブジェクトがいくつ存在するか

これら 5 行を「実行は成功しました」に折りたたまないでください。

3. 隠れた 2 番目のトリガーを確認する

Facebook を非難する前に、自分でコントロールできる原因を排除してください。

  • 同じページを使用する別のスケジュールされたシナリオ
  • インスタント Webhook と 1 時間ごとの検索
  • 2 番目のワークスペース、環境、または古いシナリオ
  • 同じ内容の 2 つのソース レコード
  • ページまたはビジネス スイートから行われた手動投稿
  • ステータス更新が表示される前にレコードを再度選択するポーリング ウィンドウ

タイムスタンプだけでなく、安定した識別子を使用してください。自動化シナリオ ID、ソース レコード ID、コンテンツ フィンガープリント、および宛先ページ ID を同じ行に記録します。

2 つのワークフローがソース テーブルを共有する場合は、プロバイダーが作成する前に宛先固有のクレームまたはロックを追加します。時間バッファだけでは冪等性は保証されません。

4. 遅い応答を曖昧なものとして扱う

長時間実行されている Facebook モジュールは重要な証拠ですが、それだけでは原因を特定できません。

プロバイダーが投稿を受け入れ、クライアントが応答を受信する前にタイムアウトした場合、統合によって最初の結果が調整されない限り、自動再試行によって別の投稿が作成される可能性があります。 2 つの投稿が存在するときにモジュールが 1 つのプロバイダー ID を返した場合は、一致しない投稿 ID を保持し、どのアクターがそれを作成したかを尋ねます。

安全なルールは次のとおりです。

宛先が確認されるまで、タイムアウトまたは応答の損失は、failed ではなく、unknown になります。

プロバイダー ID または一致するパブリック投稿がすでに存在する場合、その宛先の自動回復を一時停止します。

5. 2 つのポストからなる証拠台帳を構築する

プロバイダー オブジェクトごとに 1 行を使用します。

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

2 つの Facebook 投稿の場合、自動化プラットフォームが 1 つの実行を公開する場合でも、台帳には 2 行が含まれている必要があります。一致しないフィールドは、調査により強力な証拠が必要な場所を示しています。

6. 宛先スコープの回復ゲートを追加する

作成または再試行する前に、そのページの既存のレコードを確認してください。

  1. プロバイダーポスト ID はすでに存在しますか? 2.保存されたパーマリンクはありますか?
  2. 公開ページには、予想される時間枠内で一致するコンテンツのフィンガープリントが含まれていますか?
  3. 不完全な実行でも作成モジュールを再試行できますか?

結果があいまいな場合は、アイテムを再度作成するのではなく、手動調整に移動します。マルチチャネル バッチが部分的に成功した場合は、自身のプロバイダーの状態を確認した後、未解決の宛先のみを再試行します。

このゲートは、すべてのプロバイダーが冪等性キーを公開することを保証するものではありません。これにより、回復ロジックがクライアント確認の欠落を何も作成されていない証拠として扱うことを防ぎます。

別のネットワークからの実際の部分成功警告

別の ANKK スレッド インシデントでは、スケジュールされたルートが 1 つ公開され、応答ステップでプロバイダーが利用できない結果が発生しました。オペレーターが手動で再試行しなかった場合でも、自動回復により 2 つの同一の公開応答が生成されました。プロバイダーのオリジナルと安定したコンテンツとジョブ ID は、製品調査のために保存されました。

Threads の事件は、Facebook の重複の原因を証明するものではありません。これは一般的な障害境界を示しています。いずれかのセグメントがプロバイダーに到達すると、回復には操作全体をブラインドでリプレイするのではなく、そのセグメントでのプロバイダーの調整が必要になります。

ソースと次のステップ

ANKKを運営しています。 ANKK には AI ライターが組み込まれていません。人、外部 AI ツール、またはスクリプトによって準備されたコンテンツを、ソーシャル スケジュール、チャネル レベルの状態、プロバイダー独自の検証に接続します。

ANKK 開発者のワークフローを確認する