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

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.