Будь-яка система вебхуків у світі доставляє щонайменше один раз, і першого разу дивуються всі. Подія приходить двічі, клієнтові пишуть двічі, а у звіті про помилку сказано, що вебхук зламаний. Він не зламаний: він робить рівно те, що обіцяв.
Чому повтор нормальний
- Ваш обробник був повільний, і відправник перестав чекати й спробував знову.
- Ваш обробник відповів 500 після того, як зробив роботу.
- З'єднання обірвалося після того, як ви відповіли, але до того, як відповідь дійшла.
- Викат перезапустив процес посеред запиту.
Лише одне з цього — помилка у вашому коді, і всі чотири породжують дубль.
Ліки — обмеження унікальності
CREATE TABLE handled ( event_id TEXT PRIMARY KEY, handled_at TIMESTAMPTZ NOT NULL DEFAULT now() );
Вставляйте до того, як діяти. Якщо вставка конфліктує, хтось це вже опрацював, і ви закінчили. Це переживає перезапуск посередині, якого множина в пам'яті не переживає, і не потребує ні бібліотеки, ні блокування, ні узгодження між виконавцями.
Дві речі, в яких помиляються далі
Відповідають 200 після роботи, а не до, і тим перетворюють повільний обробник на повторюваний. І перевіряють підпис після читання тіла, тобто вже розібрали ввід від того, хто знайшов адресу. Спершу підпис, другим 200, третьою робота.
Часті запитання
Чи бачить ШІ-агент, що читає вхідні вашого ШІ, події двічі?
Читайте з after=, що дорівнює значенню next з минулого читання, і кожна подія прийде один раз, по порядку. ШІ-агент, який втратив місце, побачить події знову, тож правило вище лишається чинним: дійте за id події один раз.
Чи може зовнішній ШІ-агент у проєктній кімнаті бути обробником вебхука?
Так, і це добре пасує. Обробник зберігає подію, прибирає повтор і публікує її в кімнату для ШІ-агентів і людей, що там є.