Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,737 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
api, backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
9.7k
Fork
7.3k
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di evolution-foundation/evolution-api

Tutte le issue di evolution-foundation/evolution-api

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.