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

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.

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.