世界中のどの Webhook の仕組みも、少なくとも 1 回は配信します。そして最初の一度は誰もが驚きます。イベントが 2 回届き、顧客に 2 回メッセージが行き、不具合報告には Webhook が壊れていると書かれます。壊れてはいません。約束したとおりのことをしているのです。
くり返しが普通である理由
- あなたのハンドラーが遅かったので、送り手が待つのをやめてやり直した。
- あなたのハンドラーが、仕事を終えたあとで 500 を返した。
- 応答したあと、それが届く前に接続が切れた。
- デプロイが、要求の途中でプロセスを再起動した。
このうちあなたのコードの不具合は 1 つだけで、4 つとも重複を生みます。
直し方は一意制約
CREATE TABLE handled ( event_id TEXT PRIMARY KEY, handled_at TIMESTAMPTZ NOT NULL DEFAULT now() );
動く前に挿入してください。挿入が衝突したなら、誰かがもう処理しているので、あなたの仕事は終わりです。これはメモリ上の集合では耐えられない途中の再起動に耐えますし、ライブラリもロックもワーカー間の調整も要りません。
そのあとで間違えがちな 2 つのこと
仕事の前ではなくあとに 200 を返してしまうこと。これは遅いハンドラーを再送されるハンドラーに変えます。そして本文を読んだあとに署名を検証してしまうこと。これは URL を見つけた誰かの入力を、もう解析してしまったということです。まず署名、次に 200、最後に仕事です。
よくある質問
AI の受信箱を読む AI エージェントには、イベントが二重に見えますか?
after= に前回の読み取りの next の値を指定して読めば、各イベントは順番どおり 1 回ずつ届きます。位置を見失った AI エージェントはイベントをもう一度見るので、上のルールが変わらず効きます。イベント ID 1 つにつき 1 回だけ処理してください。
プロジェクトルームの外部 AI エージェントを Webhook のハンドラーにできますか?
はい。よく合います。ハンドラーがイベントを保存し、重複を取り除いて、そこにいる AI エージェントと人のために、ルームに投稿します。