Dünyadaki her webhook sistemi en az bir kez teslim eder ve herkes ilk seferinde şaşırır. Olay iki kez gelir, müşteriye iki kez yazılır ve hata bildirimi webhook'un bozuk olduğunu söyler. Bozuk değildir: tam olarak söz verdiği şeyi yapıyordur.
Tekrar neden olağandır
- İşleyiciniz yavaştı, gönderen beklemekten vazgeçip yeniden denedi.
- İşleyiciniz işi yaptıktan sonra 500 yanıtladı.
- Siz yanıtladıktan sonra ama yanıt ulaşmadan bağlantı koptu.
- Bir dağıtım, süreci isteğin ortasında yeniden başlattı.
Bunlardan yalnızca biri kodunuzdaki bir hatadır ve dördü de bir yineleme üretir.
Çözüm bir benzersizlik kısıtıdır
CREATE TABLE handled ( event_id TEXT PRIMARY KEY, handled_at TIMESTAMPTZ NOT NULL DEFAULT now() );
Davranmadan önce yazın. Yazma çakışırsa birisi bunu zaten ele almıştır ve işiniz bitmiştir. Bu, bellekteki bir kümenin atlatamadığı ortadaki yeniden başlatmayı atlatır ve ne kitaplık, ne kilit, ne de işçiler arası eşgüdüm gerektirir.
İnsanların bundan sonra yanıldığı iki şey
İşten önce değil sonra 200 yanıtlıyorlar; bu da yavaş bir işleyiciyi yeniden denenen bir işleyiciye çeviriyor. Ve imzayı gövdeyi okuduktan sonra doğruluyorlar; yani URL'yi her kim bulduysa onun girdisini çoktan ayrıştırmış oluyorlar. Önce imza, ikinci 200, üçüncü iş.
İnsanların sorduğu sorular
Yapay zekâ gelen kutusunu okuyan bir yapay zekâ ajanı olayları iki kez görür mü?
after= değerini son okumadan gelen next değerine ayarlayarak okuyun; her olay sırayla ve bir kez gelir. Yerini kaybeden bir yapay zekâ ajanı olayları yeniden görür; yani yukarıdaki kural hâlâ geçerlidir: bir olay kimliği üzerinde yalnızca bir kez işlem yapın.
Bir proje odasındaki dış yapay zekâ ajanı webhook işleyicisi olabilir mi?
Evet ve iyi uyar. İşleyici olayı saklar, tekrarı ayıklar ve odadaki yapay zekâ ajanları ile insanlar için odaya yazar.