v2.3.X: Unique Incoming Messages Incorrectly Flagged as "Duplicated" and Not Sent to Webhook

[sluy]

Welcome!

• [x] Yes, I have searched for similar issues on GitHub and found none.

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

[cleytoncoro]

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****

[cleytoncoro]

Ah, estou usando REDIS também // I'm using REDIS here too.

[joaovcoliveira]

Same happening here for a while

[KokeroO]

Essas mensagens ignoradas são de ADS?

[cleytoncoro]

Não. São mensagens normais.

[cleytoncoro]

Vi alguns relatos de mensagens sendo perdidas lá no discord tbm. Talvez seja o mesmo problema.

[joaovcoliveira]

Essas mensagens ignoradas são de ADS?

Inicialmente os problemas eram só com mensagens provenientes de ads (como reportei aqui: https://github.com/EvolutionAPI/evolution-api/issues/2066), mas ultimamente até mensagens normais estão passando por isso.

[cleytoncoro]

Para ajudar no debug eu posso afirmar com segurança que:

1. são mensagens de usuários normais. não são ads.
2. o ID da mensagem perdida (conferi no WA web olhando a store) é o mesmo ID que está no log como "duplicated".
3. 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).

[KokeroO]

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.

[BryanLucas7]

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.

[cleytoncoro]

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.

[cleytoncoro]

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.

[KokeroO]

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

[KokeroO]

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.

[cleytoncoro]

Sobre a call, como é um erro intermitente, acho difícil simular. Vou monitorar aqui e se tiver alguma informação extra eu posto. Vou dar uma lida no código tbm e tentar entende o fluxo com base nos logs pra tentar achar alguma hipótese.

[RamonSouza96]

Olá pessoal, estou com mesmo problema, identifiquei que em algumas poucas mensagens não estão chegando no chatwoot

Estou usando a Evolution API v2.3.5 com Chatwoot v4.6.0 e algumas mensagens do WhatsApp não estão chegando no sistema. As mensagens aparecem no WhatsApp, mas não são processadas no Chatwoot.

O que identifiquei nos logs:

1. Mensagens sendo marcadas como duplicadas (igual ao issue #2110): "INFO [ChannelStartupService] Message duplicated ignored: ACFCDA78F605C624FDD6CE9EF1A21822"

2. Erro de autenticação PostgreSQL "ERROR [ChatwootImport] Error on getExistingSourceIds: error: password authentication failed for user "postgres""

WARN [ChannelStartupService] Original message not found for update. Skipping. Key: {"remoteJid":"[email protected]","id":"ACA23D66E17DDE6E0E6852289106BC4E","fromMe":false}

4. Mensagens originais não encontradas: Exemplos das mensagens que não chegaram: +55 62 9456-308: "Olá Preciso de mais informações sobre Planos" +55 92 8123-388: "Boa tarde" +55 75 8158-165: "Oi boa noite já respondi o formulário obrigado boa noite"

Coloquei esse relato aqui caso ajude em alguma coisa na correção, vou tentar fazer um update da evo para 2.3.6

[cleytoncoro]

@KokeroO existe a possibilidade do código abaixo estar ignorando o valor de CACHE_REDIS_PREFIX_KEY no momento de consultar ou salvar o cache?

Pois aqui no meu cenário eu tenho 2 instâncias da evolution, e nas 2 eu tenho o mesmo WA conectado. Ou seja, pode justificar uma colisão de IDs nas 2, caso o prefix_key não esteja sendo aplicado corretamente. Uma instância cria a mensagem, a outra tenta mas o cache não deixa, pq acha que aquela instância tbm já criou.

[cleytoncoro]

Acho que pode ser isso. Talvez vc precisasse passar a sua messageKey primeiro aqui: messageKey = this.baileysCache.buildKey(messageKey)

É só uma hipótese. Estou um pouco corrido aqui para aprofundar. Se puder confirmar.

[cleytoncoro]

Além disso me ocorreu outro cenário: e se conectar o mesmo whatsapp 2 vezes na mesma instância?

[KokeroO]

@KokeroO existe a possibilidade do código abaixo estar ignorando o valor de CACHE_REDIS_PREFIX_KEY no momento de consultar ou salvar o cache?

Pois aqui no meu cenário eu tenho 2 instâncias da evolution, e nas 2 eu tenho o mesmo WA conectado. Ou seja, pode justificar uma colisão de IDs nas 2, caso o prefix_key não esteja sendo aplicado corretamente. Uma instância cria a mensagem, a outra tenta mas o cache não deixa, pq acha que aquela instância tbm já criou.

ele valida por instanceId, o cache nao deve conflitar ai.

Teste com a 2.3.6 e veja como ficou. O problema de nao recber ads foi resolvido.

[daniel-eder]

it validates by instanceId, the cache should not conflict there.

Try 2.3.6 and see how it goes. The issue of not receiving ads has been resolved.

@KokeroO The issue seems to remain, I just got: 2025-10-24T20:18:21.550829829Z [Evolution API] [Daniel Eder] v2.3.6 170 - Fri Oct 24 2025 17:18:21 INFO [ChannelStartupService] [string] Message duplicated ignored [avoid deadlock]: 128441f6-5504-441a-86b8-f7ae504b26ef_3EB0C0BD05DCA97A7C09CB_3

It seems to happen to all unique messages, I have not got any MESSAGES_UPSERT on the webhook for the last 20+ messages I tested.

[KokeroO]

@daniel-eder I can't understand why you're not receiving webhooks, there's something wrong with your configuration.

2025-10-24T20:18:21.550829829Z [Evolution API] [Daniel Eder] v2.3.6 170 - Fri Oct 24 2025 17:18:21 INFO [ChannelStartupService] [string] Message duplicated ignored [avoid deadlock]: 128441f6-5504-441a-86b8-f7ae504b26ef_3EB0C0BD05DCA97A7C09CB_3

Don't rely on this ignored message alert. This alert indicates that you ignored the repeated update of the message status. In this case, you ignored the message delivered mark.

This serves to reduce Postgres overload and excessive event triggering in integrations. That's all.

[daniel-eder]

Hmm that is odd because my webhook updates stopped working without a change in configuration either on the receiving side or the evolution api side. Also, all other webhooks work, only the message upsert no longer sends.

But I will investigate further on my end!

EDIT: You are right, there was a different issue. I first disconnected and reconnected the instance, that did not work. Deleting the instance and creating a new did work. I am not sure if there is a reproducible bug or if the instance just somehow got out of sync, but re-creating the instance works :)

[KokeroO]

Hmm. Are you just waiting for them via webohhok? Check when it happens again if, when you wait for the upsert, there will be a duplicate message event without the status number at the end of the cachekey: Message duplicated ignored [avoid deadlock]: 128441f6-5504-441a-86b8-f7ae504b26ef_3EB0C0BD05DCA97A7C09CB

If not, you're actually ignoring the trigger, so there's a problem.

[abdelrhmanfawzym]

i have similar issue some messages received in whatsapp but doesn't received on evolution api last Version: 2.3.6

[joaovcoliveira]

still 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 🌹"
} [0m

[fcperez96]

still 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 🌹"
} �[0m

Same issue here, same version

[juliancesar]

+1 - 2.3.6

[juniortopanotti]

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.

[pedroarthuralvesdeoliveira]

UP