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.
Bug Description
Same root cause as #2675 / PR #2716 ("live path has no idempotency check on
key.idredelivery"), 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, samemessageTimestamp), themessages.upserthandler processes it a second time and callschatbotController.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
Messagetable with the exact same WhatsAppkey.idandmessageTimestamp, inserted as separate records:Confirmed via the Typebot side too: the bot's
AnswerV2log 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@lidcontacts 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
2.4.0-rc23.19.0(baptistearno/typebot-builder/typebot-viewer)evolution-api,postgres,redis,typebot-builder,typebot-viewer), Baileys channel/typebot/create, keyword trigger)Suggested fix
#2716 adds the
key.id-based idempotency check (viagetExistingSourceIds/cache) specifically inside the Chatwoot code path. Since the redelivery happens upstream of any specific integration — at themessages.upserthandler inwhatsapp.baileys.service.ts, right wherechatbotController.emit(...)is called — placing an equivalent dedup check there (or inchatbotController.emititself) 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.