Riwayat otomatisasi Anda menunjukkan satu proses yang berhasil dan satu paket keluaran. Facebook menampilkan dua postingan.

Bukti tersebut mengesampingkan beberapa penjelasan sederhana, namun tidak membuktikan sistem mana yang menduplikasi penulisan tersebut. Jangan jalankan otomatisasi lagi. Simpan kedua provider original dan buat satu baris bukti untuk setiap tulisan yang mungkin sampai ke Facebook.

Daftar periksa ini mencakup kasus spesifik di mana alur kerja Airtable, Make, n8n, atau kustom tampak berjalan satu kali saat Halaman Facebook menerima postingan duplikat.

Jawaban singkatnya

Sebelum mengubah skenario, catat:

  1. ID eksekusi otomatisasi dan waktu mulai/berakhir yang tepat
  2. setiap bundel masukan atau ID rekaman sumber
  3. coba lagi, eksekusi tidak lengkap, dan riwayat batas waktu
  4. setiap ID postingan Facebook dan tautan permanen
  5. stempel waktu publik dan konten yang dirender dari setiap postingan

Jika dua postingan Facebook memiliki provider ID yang berbeda, ada dua pembuatan sisi penyedia meskipun UI otomatisasi merangkum pekerjaan sebagai satu proses. Pertanyaan selanjutnya adalah dari mana pembuatan kedua berasal: pemicu lain, percobaan ulang otomatis, pemulihan batas waktu, duplikat sisi penyedia, atau klien terpisah yang menggunakan rekaman sumber yang sama.

Jangan beri label penyebabnya sampai bukti dapat membedakan jalur tersebut.

1. Simpan kedua dokumen asli publik terlebih dahulu

Buka kedua postingan Facebook sebelum menghapus atau mengedit salah satunya. Untuk setiap postingan, ambil:

  • Identitas halaman
  • ID pos penyedia
  • tautan permanen
  • stempel waktu yang diterbitkan
  • keterangan dan media yang tepat
  • pengarang atau atribusi penerbitan yang terlihat

Bandingkan teks dan sidik jari media. Dua keterangan yang identik tidak membuktikan bahwa permintaan yang sama telah diulang; dua klien independen dapat mengirim catatan sumber yang sama. Dua provider ID yang berbeda membuktikan bahwa penyedia menerima dua pembuatan.

Jika hanya satu tautan permanen yang tersedia dan postingan kedua masih terlihat, simpan tangkapan layar dan stempel waktu publik saat Anda menyelidikinya. Tandai ID yang hilang sebagai unknown.

2. Pisahkan skenario yang dijalankan dari penulisan penyedia

Otomatisasi ramah lingkungan berarti orkestrasi selesai berdasarkan aturan platform tersebut. Ini tidak berarti terjadi satu penulisan eksternal.

Membuat dokumen yang kegagalan koneksi, batas kecepatan, dan batas waktu dapat dicoba ulang melalui eksekusi yang tidak lengkap dan backoff eksponensial. Dokumentasinya juga mencatat bahwa tindakan dalam aplikasi eksternal non-transaksional tidak dapat dibatalkan. Oleh karena itu, pembuatan penyedia mungkin berhasil bahkan ketika langkah klien berikutnya kehabisan waktu atau kehilangan respons.

Periksa ini secara terpisah:

Lapisan Bukti untuk dikumpulkan Apa yang bisa dibuktikan
Pemicu jadwal/waktu webhook dan ID pemicu berapa banyak proses yang dimulai
Sumber ID catatan airtable dan jumlah bundel masukan berapa banyak catatan yang masuk aliran
Buat modul operasi modul, waktu mulai/berakhir, keluaran mentah berapa banyak panggilan penyedia yang dicatat platform
Coba lagi sistem eksekusi tidak lengkap, percobaan ulang otomatis, riwayat backoff apakah panggilan gagal atau ambigu dijalankan lagi
Facebook setiap ID postingan dan permalink berapa banyak objek penyedia publik yang ada

Jangan ciutkan kelima baris ini menjadi "proses berhasil".

3. Periksa pemicu kedua yang tersembunyi

Sebelum menyalahkan Facebook, hilangkan penyebab yang dapat Anda kendalikan:

  • skenario terjadwal lainnya menggunakan Halaman yang sama
  • webhook instan ditambah pencarian setiap jam
  • ruang kerja kedua, lingkungan, atau skenario lama
  • dua catatan sumber dengan konten yang sama
  • postingan manual yang dibuat dari Halaman atau Business Suite
  • jendela polling yang memilih kembali rekaman sebelum pembaruan statusnya terlihat

Gunakan pengenal yang stabil, bukan hanya stempel waktu. Catat ID skenario otomatisasi, ID rekaman sumber, sidik jari konten, dan ID Halaman tujuan di baris yang sama.

Jika dua alur kerja berbagi tabel sumber, tambahkan klaim atau kunci khusus tujuan sebelum penyedia membuat. Buffer waktu saja bukanlah jaminan idempotensi.

4. Perlakukan respons yang lambat sebagai sesuatu yang ambigu

Modul Facebook yang sudah berjalan lama merupakan bukti penting, namun modul tersebut tidak dapat mengidentifikasi penyebabnya dengan sendirinya.

Jika penyedia menerima postingan dan waktu klien habis sebelum menerima respons, percobaan ulang otomatis dapat membuat postingan lain kecuali integrasi merekonsiliasi hasil pertama. Jika modul mengembalikan satu provider ID sementara ada dua postingan, pertahankan ID postingan yang tidak cocok dan tanyakan aktor mana yang membuatnya.

Aturan amannya adalah:

Respon yang habis atau hilang adalah unknown, bukan failed, hingga tujuan dicentang.

Jeda pemulihan otomatis untuk tujuan tersebut ketika provider ID atau postingan publik yang cocok sudah ada.

5. Buatlah buku besar bukti dua tiang

Gunakan satu baris per objek penyedia:

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

Untuk dua postingan Facebook, buku besar harus berisi dua baris meskipun platform otomatisasi menampilkan satu baris. Bidang-bidang yang tak tertandingi menunjukkan di mana penyelidikan memerlukan bukti yang lebih kuat.

6. Tambahkan gerbang pemulihan dengan cakupan tujuan

Sebelum membuat atau mencoba lagi, periksa catatan yang ada untuk Halaman tersebut:

  1. Apakah sudah ada ID kiriman penyedia?
  2. Apakah ada permalink yang tersimpan?
  3. Apakah Halaman publik berisi sidik jari konten yang cocok dalam jangka waktu yang diharapkan?
  4. Apakah eksekusi yang tidak lengkap masih memenuhi syarat untuk mencoba kembali modul pembuatan?

Jika hasilnya tidak jelas, pindahkan item ke rekonsiliasi manual daripada membuat lagi. Ketika kumpulan multisaluran berhasil sebagian, coba lagi hanya tujuan yang belum terselesaikan setelah memeriksa status penyedianya sendiri.

Gerbang ini tidak menjamin bahwa setiap penyedia mengekspos kunci idempotensi. Ini mencegah logika pemulihan Anda memperlakukan konfirmasi klien yang hilang sebagai bukti bahwa tidak ada yang dibuat.

Peringatan keberhasilan parsial yang nyata dari jaringan lain

Dalam insiden Thread ANKK terpisah, satu root terjadwal diterbitkan dan langkah balasan mengalami hasil yang tidak tersedia oleh penyedia. Pemulihan otomatis menghasilkan dua balasan publik yang identik meskipun operator tidak melakukan percobaan ulang secara manual. Konten asli dan stabil penyedia serta job ID disimpan untuk penyelidikan produk.

Insiden Threads tersebut tidak membuktikan penyebab duplikat Facebook. Hal ini menunjukkan batas kegagalan umum: ketika suatu segmen telah mencapai penyedia, pemulihan memerlukan rekonsiliasi penyedia di segmen tersebut daripada mengulang seluruh operasi secara buta.

Sumber dan langkah selanjutnya

Saya mengoperasikan ANKK. ANKK tidak menyertakan penulis AI bawaan. Ini menghubungkan konten yang disiapkan oleh manusia, alat AI eksternal, atau skrip dengan penjadwalan sosial, status tingkat saluran, dan verifikasi provider original.

Tinjau alur kerja pengembang ANKK