Repository navigation
v2.3.X: Unique Incoming Messages Incorrectly Flagged as "Duplicated" and Not Sent to Webhook #2110
Description
Activity
Here too.
Recebi uma mensagem e ela não foi adicionada.
Mas identifiquei seu ID por outro app e achei que há logs relativos a ela falando que foi ignorada:
v2.3.5 163 - Mon Oct 20 2025 11:51:46 INFO [ChannelStartupService] [string] Message duplicated ignored: 3FBD63295E1412****Ah, estou usando REDIS também // I'm using REDIS here too.
Same happening here for a while
Essas mensagens ignoradas são de ADS?
Não. São mensagens normais.
Vi alguns relatos de mensagens sendo perdidas lá no discord tbm. Talvez seja o mesmo problema.
Essas mensagens ignoradas são de ADS?
Inicialmente os problemas eram só com mensagens provenientes de ads (como reportei aqui: #2066), mas ultimamente até mensagens normais estão passando por isso.
Para ajudar no debug eu posso afirmar com segurança que:
- são mensagens de usuários normais. não são ads.
- o ID da mensagem perdida (conferi no WA web olhando a store) é o mesmo ID que está no log como "duplicated".
- a mensagem não é retornada pela evolution chamando o endpoint chat/findMessages/, ou seja, não foi nem adicionada.
Sobre o item 3, verifiquei sem filtros. Ou seja, o ID da mensagem perdida não foi adicionada nem mesmo com ID diferente em outro chat (jid VS lid).
Muito estranho, porque aqui não tenho esse problema. Mas não uso com webhook, somente com chatwoot.
Eu que implementei essa rotina de mensagens ignorada. Uso a uns 8 meses nos clientes sem problemas.Aqui também, está acontecendo com a primeira mensagem em específico, seja de ads ou não. Não chega no Chatwoot e também não chega no webhook no n8n. Vou atualizar para a versão 2.3.6 para ver se melhora.
Na verdade não vai para o webhook pois ela nem é inserida no banco da evolution.
Ou seja, se não vai para o webhook, em teoria não vai para o chatwoot também.Não sei se tem relação com a rotina de ignorar mensagem. Apenas posso dizer que a mensagem chegou nos logs da evolution pois apareceu nessa linha.
Ah, a mensagem perdida em questão era a primeira enviada pela pessoa tbm. Ela enviou 3, as 2ª e 3ª foram recebidas. a primeira não.
Olha, eu ate me disponibilizo pra a gente fazer uma call e testarmos junto, vou fazendo as alterações em call até a gente descobrir onde é o problema, dai faço a correção pra a proxima versão. Porque realmente, aqui pra mim nao ocorre
Mas assim, peço que testei a 2.3.6. Porque tinha feito uma alteração que possa ser que implicava no recebimento de ADS. Precisava que fizessem um teste nessa parte.
10 remaining items
i have similar issue
some messages received in whatsapp but doesn't received on evolution api last Version: 2.3.6still facing the same issue after updating to version 2.3.6:
Looking at the logs, the only references to the contact phone number I could find are these:
�[1m�[32m[Evolution API]�[0m �[1m�[32m �[1m�[32m v2.3.6 �[1m�[32m 163 �[0m �[1m�[32m - �[1m�[37m Sat Oct 25 2025 09:13:03 �[0m �[32m�[42m�[1m LOG �[0m �[33m�[1m [BaileysMessageProcessor]�[0m �[32m�[1m [string]�[0m �[32m Processing batch of 1 messages �[0m �[1m�[36m[Evolution API]�[0m �[1m�[36m [89aa24c8-efe5-47fe-8570-05997a773e79] �[1m�[36m v2.3.6 �[1m�[36m 163 �[0m �[1m�[36m - �[1m�[37m Sat Oct 25 2025 09:13:03 �[0m �[36m�[46m�[1m DEBUG �[0m �[33m�[1m [ChannelStartupService]�[0m �[36m�[1m [string]�[0m �[36m Updating contact: { "id": "<number>@s.whatsapp.net", "notify": "🌹Cláudia 🌹" } �[0m �[1m�[32m[Evolution API]�[0m �[1m�[32m �[1m�[32m v2.3.6 �[1m�[32m 163 �[0m �[1m�[32m - �[1m�[37m Sat Oct 25 2025 09:13:03 �[0m �[32m�[42m�[1m LOG �[0m �[33m�[1m [BaileysMessageProcessor]�[0m �[32m�[1m [string]�[0m �[32m Processing batch of 1 messages �[0m �[1m�[36m[Evolution API]�[0m �[1m�[36m [89aa24c8-efe5-47fe-8570-05997a773e79] �[1m�[36m v2.3.6 �[1m�[36m 163 �[0m �[1m�[36m - �[1m�[37m Sat Oct 25 2025 09:13:03 �[0m �[36m�[46m�[1m DEBUG �[0m �[33m�[1m [ChannelStartupService]�[0m �[36m�[1m [string]�[0m �[36m Updating contact: { "id": "<number>@s.whatsapp.net", "notify": "🌹Cláudia 🌹" } �[0m �[1m�[34m[Evolution API]�[0m �[1m�[34m [89aa24c8-efe5-47fe-8570-05997a773e79] �[1m�[34m v2.3.6 �[1m�[34m 163 �[0m �[1m�[34m - �[1m�[37m Sat Oct 25 2025 09:13:03 �[0m �[34m�[44m�[1m INFO �[0m �[33m�[1m [ChannelStartupService]�[0m �[34m�[1m [string]�[0m �[34m Message duplicated ignored: AC4575535349F5F5550B05978E45DF29 �[0m Closing open session in favor of incoming prekey bundle Closing session: SessionEntry { _chains: { 'BbcT+x+gf/WJnSl9a': { chainKey: [Object], chainType: 2, messageKeys: {} }, 'Bc+NEZEm6I3yn3uLKYlkXsMP0DWnf1jEBzeL5q52b9Ab': { chainKey: [Object], chainType: 1, messageKeys: {} } }, registrationId: 1441595647, currentRatchet: { ephemeralKeyPair: { pubKey: <Buffer >, privKey: <Buffer > }, lastRemoteEphemeralKey: <Buffer >, previousCounter: 0, rootKey: <Buffer 0> }, indexInfo: { baseKey: <Buffer >, baseKeyType: 2, closed: -1, used: 1761394383397, created: 1761394383397, remoteIdentityKey: <Buffer > } } �[1m�[32m[Evolution API]�[0m �[1m�[32m �[1m�[32m v2.3.6 �[1m�[32m 163 �[0m �[1m�[32m - �[1m�[37m Sat Oct 25 2025 09:13:04 �[0m �[32m�[42m�[1m LOG �[0m �[33m�[1m [BaileysMessageProcessor]�[0m �[32m�[1m [string]�[0m �[32m Processing batch of 1 messages �[0m �[1m�[36m[Evolution API]�[0m �[1m�[36m [89aa24c8-efe5-47fe-8570-05997a773e79] �[1m�[36m v2.3.6 �[1m�[36m 163 �[0m �[1m�[36m - �[1m�[37m Sat Oct 25 2025 09:13:04 �[0m �[36m�[46m�[1m DEBUG �[0m �[33m�[1m [ChannelStartupService]�[0m �[36m�[1m [string]�[0m �[36m Updating contact: { "id": "<number>@s.whatsapp.net", "notify": "🌹Cláudia 🌹" } �[0mstill facing the same issue after updating to version 2.3.6:
Looking at the logs, the only references to the contact phone number I could find are these:
�[1m�[32m[Evolution API]�[0m �[1m�[32m �[1m�[32m v2.3.6 �[1m�[32m 163 �[0m �[1m�[32m - �[1m�[37m Sat Oct 25 2025 09:13:03 �[0m �[32m�[42m�[1m LOG �[0m �[33m�[1m [BaileysMessageProcessor]�[0m �[32m�[1m [string]�[0m �[32m Processing batch of 1 messages �[0m �[1m�[36m[Evolution API]�[0m �[1m�[36m [89aa24c8-efe5-47fe-8570-05997a773e79] �[1m�[36m v2.3.6 �[1m�[36m 163 �[0m �[1m�[36m - �[1m�[37m Sat Oct 25 2025 09:13:03 �[0m �[36m�[46m�[1m DEBUG �[0m �[33m�[1m [ChannelStartupService]�[0m �[36m�[1m [string]�[0m �[36m Updating contact: { "id": "<number>@s.whatsapp.net", "notify": "🌹Cláudia 🌹" } �[0m �[1m�[32m[Evolution API]�[0m �[1m�[32m �[1m�[32m v2.3.6 �[1m�[32m 163 �[0m �[1m�[32m - �[1m�[37m Sat Oct 25 2025 09:13:03 �[0m �[32m�[42m�[1m LOG �[0m �[33m�[1m [BaileysMessageProcessor]�[0m �[32m�[1m [string]�[0m �[32m Processing batch of 1 messages �[0m �[1m�[36m[Evolution API]�[0m �[1m�[36m [89aa24c8-efe5-47fe-8570-05997a773e79] �[1m�[36m v2.3.6 �[1m�[36m 163 �[0m �[1m�[36m - �[1m�[37m Sat Oct 25 2025 09:13:03 �[0m �[36m�[46m�[1m DEBUG �[0m �[33m�[1m [ChannelStartupService]�[0m �[36m�[1m [string]�[0m �[36m Updating contact: { "id": "<number>@s.whatsapp.net", "notify": "🌹Cláudia 🌹" } �[0m �[1m�[34m[Evolution API]�[0m �[1m�[34m [89aa24c8-efe5-47fe-8570-05997a773e79] �[1m�[34m v2.3.6 �[1m�[34m 163 �[0m �[1m�[34m - �[1m�[37m Sat Oct 25 2025 09:13:03 �[0m �[34m�[44m�[1m INFO �[0m �[33m�[1m [ChannelStartupService]�[0m �[34m�[1m [string]�[0m �[34m Message duplicated ignored: AC4575535349F5F5550B05978E45DF29 �[0m Closing open session in favor of incoming prekey bundle Closing session: SessionEntry { _chains: { 'BbcT+x+gf/WJnSl9a': { chainKey: [Object], chainType: 2, messageKeys: {} }, 'Bc+NEZEm6I3yn3uLKYlkXsMP0DWnf1jEBzeL5q52b9Ab': { chainKey: [Object], chainType: 1, messageKeys: {} } }, registrationId: 1441595647, currentRatchet: { ephemeralKeyPair: { pubKey: <Buffer >, privKey: <Buffer > }, lastRemoteEphemeralKey: <Buffer >, previousCounter: 0, rootKey: <Buffer 0> }, indexInfo: { baseKey: <Buffer >, baseKeyType: 2, closed: -1, used: 1761394383397, created: 1761394383397, remoteIdentityKey: <Buffer > } } �[1m�[32m[Evolution API]�[0m �[1m�[32m �[1m�[32m v2.3.6 �[1m�[32m 163 �[0m �[1m�[32m - �[1m�[37m Sat Oct 25 2025 09:13:04 �[0m �[32m�[42m�[1m LOG �[0m �[33m�[1m [BaileysMessageProcessor]�[0m �[32m�[1m [string]�[0m �[32m Processing batch of 1 messages �[0m �[1m�[36m[Evolution API]�[0m �[1m�[36m [89aa24c8-efe5-47fe-8570-05997a773e79] �[1m�[36m v2.3.6 �[1m�[36m 163 �[0m �[1m�[36m - �[1m�[37m Sat Oct 25 2025 09:13:04 �[0m �[36m�[46m�[1m DEBUG �[0m �[33m�[1m [ChannelStartupService]�[0m �[36m�[1m [string]�[0m �[36m Updating contact: { "id": "<number>@s.whatsapp.net", "notify": "🌹Cláudia 🌹" } �[0mSame issue here, same version
+1 - 2.3.6
Mesmo problema aqui, desde quando comecei a utilizar a evolution, não lembro a versão mas me ocorre desde a 2.3.0
[Evolution API] [prod-disparando-wpp] v2.3.6 156 - Wed Oct 29 2025 07:52:31 INFO [ChannelStartupService] [string] Message duplicated ignored: AC434CB94FEA59E11A71B84192B93127
De cada 10 contatos, 3 ocorre esse problema seja na primeira mensagem ou qualquer outra se a conversa ja ta iniciada.
Não loga no console o upsert como deveria, só aparenta o erro e os webhooks e sqs não são disparados.
Reacted by João OliveiraUP
Same problem here in version 2.3.6. The frequency of the problem seems to be progressively increasing.
Look this PR:
Eu tenho uma teoria: percebo que esse problema acontece majoritariamente com anúncios, mas não somente com anúncios. Eu já tive problemas em que a mensagem descartada era um link que a pessoa mandou. Mas percebo um padrão: mensagens com link preview ou outros metadados.
Fiz uma rápida análise aqui e constatei que nesses casos são enviados dois eventos:
notifyeappend. O notify contém o texto puro da mensagem e o append agrega link preview, metadados e afins.Conclusão: Por race condition, latência de rede, enfim, o
appendchega antes donotify. Ele vai gravar no cache, pois a chave é instancia_id, porém vai ser descartado mais adiante, pois não possuimessage.const messageKey = `${this.instance.id}_${received.key.id}`; const cached = await this.baileysCache.get(messageKey); if (cached && !editedMessage && !requestId) { this.logger.info(`Message duplicated ignored: ${received.key.id}`); continue; } await this.baileysCache.set(messageKey, true, this.MESSAGE_CACHE_TTL_SECONDS); if ( (type !== 'notify' && type !== 'append') || editedMessage || received.message?.pollUpdateMessage || !received?.message ) { continue; }
Proposta de solução 1: validar se a mensagem é válida antes de salvar no cache:
const messageKey = `${this.instance.id}_${received.key.id}`; const cached = await this.baileysCache.get(messageKey); if (cached && !editedMessage && !requestId) { this.logger.info(`Message duplicated ignored: ${received.key.id}`); continue; } // primeiro descarta if ( (type !== 'notify' && type !== 'append') || editedMessage || received.message?.pollUpdateMessage || !received?.message ) { continue; } // só salva se não for descartável await this.baileysCache.set(messageKey, true, this.MESSAGE_CACHE_TTL_SECONDS);
Proposta de solução 2: diferenciar
notifyeappendna lógica de deduplicação:// adiciona _${type} const messageKey = `${this.instance.id}_${received.key.id}_${type}`; const cached = await this.baileysCache.get(messageKey); if (cached && !editedMessage && !requestId) { this.logger.info(`Message duplicated ignored: ${received.key.id}`); continue; } await this.baileysCache.set(messageKey, true, this.MESSAGE_CACHE_TTL_SECONDS); if ( (type !== 'notify' && type !== 'append') || editedMessage || received.message?.pollUpdateMessage || !received?.message ) { continue; }
mesmo problema por aqui, na 2.3.6, uso o redis e a evolution, primeira mensagem (resto chega normal), seguem os logs:
nem a v2.3.7 resolveu aqui
Reacted by Róbson Rosaaqui ainda com problemade duplicar msgs, estou na 2.3.7
Resolvi o meu problema de as vezes perder a primeira mensagem de um novo contato.
Não sei se funcionará para todo mundo, eu utilizo o portainer e nele eu uso uma stack para montar a evolution, voce pode analisar o que eu fiz, adaptar pro seu cenário/aplicação e testar se funciona, faça um backup das informações originais antes!
Comigo o motivo provável é uma Race Condition (Condição de Corrida).
🔴 O Problema
Ao receber um contato novo, a Evolution API dispara vários webhooks quase simultaneamente:Criação de Contato (CONTACTS_UPSERT)
Criação de Chat (CHATS_UPSERT)
Atualização de Presença (PRESENCE_UPDATE)
Mensagem Recebida (MESSAGES_UPSERT)
Isso causa um gargalo no processamento do receptor. Muitas vezes, a mensagem é descartada porque o sistema ainda está tentando processar a criação do contato ou do chat.
🟢 A Solução
A solução consiste em desativar os webhooks redundantes. Como o payload de MESSAGES_UPSERT já contém as informações do contato e do chat, os outros eventos são desnecessários para a maioria dos fluxos.Principais mudanças:
Desativar PRESENCE_UPDATE: Este é o maior causador de ruído.
Desativar CONTACTS_* e CHATS_*: Evita a disputa de escrita no banco de dados.
Manter apenas MESSAGES_UPSERT=true: Foco total no recebimento da mensagem.
Exemplo de uma stack yaml (a minha ta basicamente assim mas com umas infos a mais)
version: "3.7"
services:
evolution_api:
image: evoapicloud/evolution-api:latest
volumes:
- evolution_instances:/evolution/instances
networks:
- network_public
environment:
- SERVER_URL=https://sua-api.dominio.com.br
- AUTHENTICATION_TYPE=apikey
- AUTHENTICATION_API_KEY=SUA_CHAVE_GLOBAL_AQUI
- LANGUAGE=pt-BR## Banco de Dados - DATABASE_ENABLED=true - DATABASE_CONNECTION_URI=postgresql://user:password@host:5432/database ## Cache (Essencial para estabilidade) - CACHE_REDIS_ENABLED=true - CACHE_REDIS_URI=redis://redis:6379/2 - CACHE_REDIS_SAVE_INSTANCES=true ## --- CONFIGURAÇÃO DE WEBHOOKS (CORREÇÃO DA RACE CONDITION) --- - WEBHOOK_GLOBAL_ENABLED=false - WEBHOOK_EVENTS_MESSAGES_UPSERT=true # Único essencial para entrada - WEBHOOK_EVENTS_MESSAGES_SET=false # Evita spam no carregamento - WEBHOOK_EVENTS_PRESENCE_UPDATE=false # O "Vilão" - Mantenha false - WEBHOOK_EVENTS_CONTACTS_UPSERT=false # Redundante - WEBHOOK_EVENTS_CHATS_UPSERT=false # Redundante - WEBHOOK_EVENTS_CONNECTION_UPDATE=true ## ------------------------------------------------------------- deploy: mode: replicated replicas: 1 placement: constraints: - node.role == manager labels: - traefik.enable=1 - traefik.http.routers.evolution.rule=Host(`sua-api.dominio.com.br`) - traefik.http.services.evolution.loadbalancer.server.port=8080volumes:
evolution_instances:
external: truenetworks:
network_public:
external: trueresolveram o problema?
aqui o que resolveu aparentemente foi usar a versão 2.3.4 do evolution, estou testando para ver se vai continuar funcionando. Se estiverem com problemas de não gerar o qrcode na versão 2.3.4, tentem mudar a whatsapp_version dentro da env
Welcome!
What did you do?
Hello Evolution API Team,
We are experiencing a critical issue with version v2.3.5 using the evoapicloud/evolution-api:v2.3.5 Docker image.
Bug Description
The API is incorrectly identifying some new, unique incoming messages as duplicates. When this occurs, the message is immediately discarded, leading to two major problems:
The console logs the error Duplicated ignored: [MESSAGE_ID].
The message is never emitted through the messages_upsert event to our configured webhook.
We confirm that these are not actual duplicate messages; they are completely new, unique messages being wrongfully discarded by the system.
Our current presumption is that the issue is related to the message ID cache management in Redis, which seems to be prematurely caching the message ID or misidentifying it as already processed upon initial receipt.
Steps to Reproduce
Run v2.3.5 with a correctly configured Redis instance for caching.
Receive a new, unique message from a contact.
Observe the API logs (the issue is intermittent and only affects some messages).
Current Behavior
The log displays Duplicated ignored: [MESSAGE_ID] for a message that is not a duplicate.
The messages_upsert event is not triggered, and the message data is not sent to the webhook.
Expected Behavior
All new and unique messages should be processed correctly.
The messages_upsert event should be reliably triggered, and the message data sent to the webhook endpoint.
Workaround (Temporary Solution)
The issue is immediately resolved by disabling the Redis cache in the Evolution API configuration. When the instance runs without Redis, all messages are processed correctly.
Note: We recognize this is not a sustainable long-term solution as it removes the intended protection against actual duplicate messages, especially after a server restart.
Thank you for your prompt attention to this matter. This bug is significantly impacting our production operations.
What did you expect?
he new messages should have been processed, and the messages_upsert event should have been reliably sent to our webhook.
What did you observe instead of what you expected?
The system incorrectly flagged the new messages as "Duplicated," logged Duplicated ignored: [MESSAGE_ID], and failed to send the event to the webhook.
Screenshots/Videos
No response
Which version of the API are you using?
2.3.X
What is your environment?
Linux
Other environment specifications
No response
If applicable, paste the log output
No response
Additional Notes
No response