Workflow n8n Bisa Terpicu Dua Kali: Cara Mencegah Data Dobel dengan Idempotency

Workflow automation tidak selalu berjalan tepat satu kali. Webhook bisa mengirim ulang request ketika respons terlambat, RSS feed dapat terbaca kembali, dan pengguna bisa menekan tombol submit dua kali. Jika workflow langsung membuat data baru tanpa pemeriksaan, hasilnya bisa berupa tiket ganda, pesan WhatsApp terkirim dua kali, atau pelanggan tercatat lebih dari sekali.

Masalah ini bukan berarti n8n bekerja secara keliru. Banyak layanan memang menggunakan mekanisme pengiriman ulang untuk memastikan data tidak hilang. Tantangannya adalah membuat workflow mampu mengenali bahwa sebuah peristiwa sudah pernah diproses.

Apa itu idempotency?

Idempotency adalah kemampuan sebuah proses untuk menghasilkan efek akhir yang sama meskipun dijalankan lebih dari sekali dengan input yang sama.

Contohnya, perintah “ubah status pesanan menjadi dibayar” relatif aman dijalankan berulang. Status akhirnya tetap “dibayar”. Sebaliknya, perintah “buat pesanan baru” tidak idempotent karena setiap pengulangan bisa menghasilkan pesanan tambahan.

Dalam workflow n8n, prinsipnya sederhana: sebelum melakukan aksi yang punya dampak, workflow perlu memeriksa apakah event tersebut sudah pernah diproses.

Kenapa workflow bisa menerima data yang sama?

• Retry dari pengirim. Sistem pengirim dapat mengirim request ulang jika tidak menerima respons tepat waktu.
• Trigger berjalan berkala. Workflow berbasis polling, termasuk sebagian skenario RSS, dapat mengambil item yang sama pada pemeriksaan berikutnya.
• Pengguna mengulang aksi. Tombol pembayaran, formulir, atau permintaan API dapat dikirim dua kali karena koneksi lambat.
• Workflow gagal di tengah jalan. Saat eksekusi diulang, langkah sebelumnya mungkin sudah berhasil meskipun langkah terakhir gagal.
• Perubahan struktur data. Jika workflow hanya membandingkan seluruh isi JSON, perubahan kecil seperti urutan field atau metadata dapat membuat data lama terlihat sebagai data baru.

n8n menyediakan daftar eksekusi yang dapat digunakan untuk meninjau workflow yang berhasil, gagal, berjalan, atau menunggu. Eksekusi yang gagal juga dapat dicoba kembali dengan workflow versi saat ini atau versi asli. Fitur ini membantu pemulihan, tetapi tidak otomatis mencegah efek ganda jika workflow tidak memiliki pemeriksaan duplikasi. Dokumentasi eksekusi n8n menjelaskan alur retry tersebut.

Tentukan kunci unik sebelum membuat workflow

Langkah pertama bukan menambahkan node, melainkan menentukan identitas sebuah event. Kunci ini sering disebut idempotency key atau event key.

Gunakan nilai yang stabil dan benar-benar mewakili satu kejadian. Contohnya:

• ID pembayaran dari payment gateway.
• ID pesan atau event dari platform chat.
• GUID atau link artikel dari RSS.
• Nomor pesanan dari toko online.
• Gabungan tanggal, alamat email, dan jenis permintaan jika sumber tidak menyediakan ID unik.

Hindari memakai waktu eksekusi n8n sebagai kunci. Jika workflow dijalankan ulang, waktu eksekusinya berubah sehingga event lama terlihat seperti event baru.

Pola workflow yang lebih aman

Struktur dasarnya dapat dibuat seperti ini:

1. Terima input. Gunakan Webhook, RSS Feed Trigger, Schedule Trigger, atau trigger dari aplikasi lain.
2. Normalisasi data. Ambil field penting dan ubah formatnya agar konsisten, misalnya memangkas spasi pada email atau mengubah URL menjadi bentuk kanonis.
3. Buat event key. Simpan ID sumber sebagai kunci utama. Jika tidak tersedia, buat gabungan field yang cukup stabil.
4. Cek riwayat. Cari event key tersebut di database, spreadsheet, Data Store, atau sistem pencatatan yang digunakan.
5. Hentikan duplikasi. Jika kunci sudah ditemukan, akhiri cabang workflow tanpa mengirim pesan atau membuat data baru.
6. Jalankan aksi utama. Hanya event baru yang boleh membuat tiket, mengirim notifikasi, atau memanggil API lanjutan.
7. Simpan penanda selesai. Catat event key setelah aksi utama berhasil.

Di n8n, node seperti Remove Duplicates dapat membantu menyaring item berulang dalam satu batch. Namun, penyaringan dalam satu eksekusi belum tentu cukup. Jika workflow berjalan lagi beberapa menit kemudian, pemeriksaan perlu memakai penyimpanan yang bertahan di luar batch tersebut.

Jangan mencatat event terlalu cepat

Ada kesalahan desain yang sering terjadi: event langsung ditandai “sudah diproses” sebelum aksi utamanya berhasil. Akibatnya, ketika pengiriman email atau pembuatan tiket gagal, percobaan berikutnya dianggap duplikat dan dilewati.

Pola yang lebih aman adalah menggunakan status sederhana:

• received: event sudah diterima.
• processing: workflow sedang mengerjakan event.
• completed: aksi utama berhasil.
• failed: aksi utama gagal dan perlu ditinjau atau dicoba kembali.

Untuk proses penting, simpan juga waktu, nama workflow, ID eksekusi, dan pesan error. Dengan begitu, pencatatan bukan hanya alat anti-duplikasi, tetapi juga jejak audit.

Bagaimana jika dua eksekusi berjalan bersamaan?

Pemeriksaan “apakah ID ini sudah ada?” bisa bermasalah ketika dua eksekusi berlangsung hampir bersamaan. Keduanya mungkin membaca database sebelum salah satunya sempat menyimpan penanda, lalu keduanya melanjutkan proses.

Solusinya adalah membuat operasi pencatatan bersifat atomik, yaitu pemeriksaan dan penyimpanan dilakukan sebagai satu operasi yang tidak mudah disela. Pada database, ini biasanya dilakukan dengan kolom unik dan perintah insert yang gagal jika nilai sudah ada. Jika menggunakan layanan lain, cari fitur seperti upsert, unique constraint, atau conditional write.

Untuk workflow yang tidak terlalu kritis, Anda dapat mengurangi risiko dengan menambahkan jeda dan pemeriksaan ulang. Namun, jeda bukan pengganti kunci unik. Ia hanya mengurangi kemungkinan tabrakan.

Contoh sederhana: RSS ke WhatsApp

Misalnya Anda ingin mengirim artikel baru dari RSS ke WhatsApp. Jangan langsung mengirim setiap item yang dibaca trigger. Ambil URL artikel sebagai event key, lalu cek apakah URL tersebut sudah ada di tabel riwayat.

1. RSS Feed Trigger menerima item.
2. Set node menormalisasi URL dan membuat field event_key.
3. Database atau penyimpanan riwayat mencari event_key.
4. IF node meneruskan hanya item yang belum ditemukan.
5. Pesan WhatsApp dikirim.
6. URL disimpan setelah pengiriman berhasil.

Jika RSS feed mengirim artikel yang sama lagi, workflow tetap berjalan, tetapi tidak mengirim pesan kedua.

Yang bisa dilakukan sekarang

• Petakan semua langkah workflow yang membuat data, mengirim pesan, atau memicu pembayaran.
• Tentukan event key yang stabil untuk setiap sumber.
• Tambahkan tabel atau penyimpanan riwayat sederhana.
• Uji dengan mengirim input yang sama dua atau tiga kali.
• Uji juga skenario gagal setelah aksi utama berhasil.
• Pastikan retry tidak membuat efek samping baru.

Otomasi yang baik bukan hanya workflow yang berhasil saat kondisi normal. Ia juga harus tetap masuk akal ketika request terlambat, data dikirim ulang, atau proses perlu diulang. Idempotency membantu memindahkan workflow dari sekadar “bisa berjalan” menjadi sistem yang lebih dapat dipercaya.

Sumber & bacaan lebih lanjut

• n8n Documentation: All executions and retry failed workflows
• n8n Documentation
• n8n Documentation: Workflow sharing and available nodes

– Rio Yotto @rioyotto