Apa yang harus dilakukan jika chatbot menjawab dua kali saat live

Tentukan dulu jenis duplikasinya

Dua jawaban identik berturut-turut bukan satu kerusakan, melainkan setidaknya dua hal berbeda. Kasus pertama: bot menerima satu peristiwa, tetapi dua kali. Kasus kedua: peristiwa yang datang hanya satu, tetapi bot mengirimnya dua kali. Penanganannya berbeda, jadi jangan mulai dengan mengubah kode — mulailah dari log.

Buka log bot dan temukan momen duplikasi. Selanjutnya perhatikan dua kolom: pengenal peristiwa dan waktu penerimaan.

• Dua permintaan dengan event_id yang sama (atau message_id, notification_id — namanya tergantung platform) dan selisih dalam milidetik — ini adalah pengiriman ulang satu peristiwa. Cari deduplikasi.
• Dua permintaan dengan pengenal berbeda — ada dua handler yang benar-benar berlangganan ke kanal. Cari langganan kedua.

Jika tidak ada log sama sekali, mulailah dari panel platform: di sana terlihat siapa yang berlangganan ke peristiwa kanal.

Seperti apa langganan ganda di panel

Platform tidak menampilkan "bot terhubung dua kali" dalam satu baris. Tandanya tersebar di berbagai bagian.

Twitch

Periksa bagian Connections di pengaturan akun — di sana ada daftar aplikasi yang terhubung. Bot yang sama bisa diotorisasi sebagai aplikasi kanal sekaligus sebagai aplikasi akun pribadi Anda. Ditambah lagi, langganan EventSub hidup terpisah: aplikasi bisa tetap memegang langganan aktif ke channel.chat.message setelah Anda memutuskan integrasi di panel. Instans bot kedua yang dijalankan secara lokal juga menerima peristiwa sama seperti yang sedang berjalan.

YouTube

Di sini yang lebih sering menjadi penyebab bukan botnya, melainkan akses ke chat: bot terhubung ke siaran sebagai moderator sekaligus sebagai akun peserta terpisah. Periksa daftar moderator dan daftar aplikasi kanal yang diotorisasi. Secara terpisah — jika bot berjalan melalui beberapa proyek Google Cloud, kunci bisa melewati dua jalur berbeda.

Discord

Kasus paling jelas: dua aplikasi dengan token yang sama di satu server. Keduanya melihat pesan di kanal dan keduanya menjawabnya. Periksa daftar bot di server dan pastikan tidak ada webhook kedua dengan nama yang sama terhubung ke kanal.

Kekurangan jalur ini — Anda perlu akses bukan hanya ke bot, tetapi juga ke panel kanal. Jika kanal dikelola beberapa orang, instans kedua mungkin dijalankan oleh orang lain, dan Anda tidak mengetahuinya.

Pengulangan webhook: mengapa peristiwa datang dua kali

Layanan eksternal mengirim webhook dan menunggu konfirmasi. Jika tidak menerima konfirmasi dalam waktu yang ditentukan — mengirimnya lagi. Permintaan kedua membawa peristiwa yang sama, tetapi bot menganggapnya baru dan menjawab lagi. Hal ini terjadi pada setiap server yang tersendat: semakin besar beban, semakin sering.

Penanganannya adalah deduplikasi di sisi bot. Diperlukan kunci yang sama untuk semua salinan satu peristiwa dan unik untuk peristiwa berbeda. Kunci diambil dari body permintaan atau header — tergantung API, tetapi polanya sama.

Contoh kunci deduplikasi

Bayangkan webhook tentang donasi baru. Di body datang objek dengan kolom id — nomor transaksi unik yang tidak berubah saat pengiriman ulang. Logikanya seperti ini:

1. Saat menerima permintaan, ambil id dari body.
2. Periksa di penyimpanan (Redis, tabel di basis data) apakah id tersebut pernah muncul dalam, katakanlah, 24 jam terakhir.
3. Jika pernah — jawab layanan dengan "diterima" dan jangan kirim apa pun ke chat.
4. Jika belum — catat dan proses seperti biasa.

Kunci harus berasal dari peristiwa itu sendiri, bukan yang Anda buat sendiri: jika membuat kunci sendiri, dua pengiriman satu peristiwa akan menghasilkan kunci berbeda, dan deduplikasi tidak akan berfungsi. Beberapa platform memberikan header siap pakai dengan pengenal pengiriman — jika ada, gunakan itu, lebih andal. Kekurangan pendekatan ini — diperlukan penyimpanan dan kebijakan pembersihan, jika tidak basis data kunci akan tumbuh tanpa batas.

Jika duplikasi datang dari dua sumber berbeda

Kasus terpisah — ketika peristiwa tidak terulang, melainkan benar-benar datang dari dua tempat. Klasik: bot menjawab perintah di chat sekaligus di penerusan antar platform melalui jembatan. Atau autoresponder diatur ke dua pemicu yang aktif pada frasa yang sama.

Duplikasi seperti ini berbeda dari pengulangan webhook berdasarkan log: permintaannya memiliki sumber berbeda (platform berbeda, handler berbeda), tetapi satu peristiwa bermakna. Cari irisan pemicu dan nonaktifkan salah satunya. Untuk jembatan — jangan teruskan pesan bot itu sendiri kembali.

Pemeriksaan sebelum live

1. Kirim perintah uji dan lihat berapa banyak jawaban yang datang.
2. Putuskan semua integrasi kecuali satu, ulangi.
3. Aktifkan satu per satu hingga duplikasi kembali muncul — dengan begitu Anda menemukan penyebabnya.
4. Cocokkan pengenal peristiwa pada kedua jawaban melalui log: sama — pengiriman ulang, berbeda — langganan kedua.

Jika penyebabnya tidak ditemukan, nonaktifkan autoresponder untuk peristiwa bermasalah dan tulis ke dukungan layanan dengan log dan waktu pengulangan. Sambil menunggu — kelola chat secara manual: lebih baik kehilangan otomatisasi selama satu malam daripada membanjiri siaran dengan frasa yang sama.