Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Chatbot integrations (Typebot/OpenAI/Dify) process the same key.id twice on device redelivery — same root cause as #2675, different code path

オープン
  • 何か問題がありますか？
#2,737 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 5 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
api, backend

調査の方向性

Begin in whatsapp.baileys.service.ts at the messages.upsert handler and trace the call to chatbotController.emit(...), using the described duplicate key.id records as the reproduction. Done means one redelivered message is not dispatched twice on the generic chatbot path, including Typebot, OpenAI, Dify, EvolutionBot, and Chatwoot.

索引モデルが issue の本文から書いたものです。

説明

Bug Description

Same root cause as #2675 / PR #2716 ("live path has no idempotency check on key.id redelivery"), but manifesting through the generic chatbot integration path (Typebot in my case — the dispatch point is shared with OpenAI/Dify/EvolutionBot, so likely affects those too), not just Chatwoot.

When a sender device redelivers the same WhatsApp message (identical key.id, same messageTimestamp), the messages.upsert handler processes it a second time and calls chatbotController.emit(...) again for the same message. If the bot session is at that moment awaiting a user reply (e.g. a button-click input step), the duplicate gets consumed as if it were the real answer — causing the flow to end prematurely, or in rarer timing windows (duplicate arriving mid-way through a slow downstream call), a second parallel bot session gets created for the same contact.

Evidence

Two rows in the Message table with the exact same WhatsApp key.id and messageTimestamp, inserted as separate records:

Row 1: key = {"id":"AC38A38C28E1A42533C197A0DF755C00","fromMe":false,"remoteJid":"<redacted>@lid"}, messageTimestamp=1790089374
Row 2: key = {"id":"AC38A38C28E1A42533C197A0DF755C00","fromMe":false,"remoteJid":"<redacted>@lid"}, messageTimestamp=1790089374

Confirmed via the Typebot side too: the bot's AnswerV2 log shows the trigger keyword itself (e.g. "pdfreceitas") captured as the answer to an unrelated later input block, ~50-200ms after the flow started — far too fast to be a real user action, consistent with the redelivery landing while the session was mid-flow.

All affected messages in my case have addressingMode: "lid" — possibly incidental (maybe @lid contacts are more prone to whatever triggers the client-side resend loop mentioned in #2675), but worth checking since #2716 also touches @lid-related edge cases (see #2718 too).

Environment

  • Evolution API: 2.4.0-rc2
  • Typebot: 3.19.0 (baptistearno/typebot-builder / typebot-viewer)
  • Deployment: Docker Swarm (separate services for evolution-api, postgres, redis, typebot-builder, typebot-viewer), Baileys channel
  • Chatbot integration: native Typebot integration (/typebot/create, keyword trigger)

Suggested fix

#2716 adds the key.id-based idempotency check (via getExistingSourceIds/cache) specifically inside the Chatwoot code path. Since the redelivery happens upstream of any specific integration — at the messages.upsert handler in whatsapp.baileys.service.ts, right where chatbotController.emit(...) is called — placing an equivalent dedup check there (or in chatbotController.emit itself) would cover Typebot/OpenAI/Dify/EvolutionBot/Chatwoot all at once, instead of needing the same fix re-implemented per integration.

Happy to test a patch against this setup if useful, or provide more logs.

主要言語
TypeScript
スター
9.8k
フォーク
7.3k
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

evolution-foundation/evolution-api のほかの issue

evolution-foundation/evolution-api の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。