@lid no Chatwoot
Welcome!
- [x] Yes, I have searched for similar issues on GitHub and found none.
What did you do?
Versões a cima da 2.3.2 está com problema na hora de mesclar no chatwoot. Está vindo @ lid no chatwoot
What did you expect?
Que o tratamento de @ lid fosse tratado tambem no Chatwoot
What did you observe instead of what you expected?
Está vindo @ lid no chatwoot
Screenshots/Videos
Which version of the API are you using?
2.3.4
What is your environment?
Windows
Other environment specifications
No response
If applicable, paste the log output
No response
Additional Notes
No response
Mesmo cenário aqui.
Por aqui também! Consigo responder normalmente, mas não resolve o número de telefone no contato do chatwoot. Edit: No log do container da evolution: key: { remoteJid: '[email protected]', //alterei o número pela privacidade, mas aparece correto no log remoteJidAlt: '210820412771912@lid', //não sei se precisaria, mas alterei também, e este que está sendo apresentado no chatwoot fromMe: false, id: '3A963996AF7A7F1EC7F8', participant: undefined, participantAlt: undefined },
Aqui também ocorreu:
Chatwoot - v4.4.0Build 5454535
Evo 2.3.4
up, mesma coisa aqui
Chatwoot v4.6.0 Evo v2.3.4
Mesma coisa aqui. Vou iniciar uma investigação esse final de semana.
Aqui também mesmo problema! https://www.youtube.com/watch?v=FueG-JnJBeo Vi esse video que talvez ajude a resolver
Tenho este problema e não uso nada de grupos @luizcw. Acabei voltando pra v2.3.2.
Tenho este problema e não uso nada de grupos @luizcw. Acabei voltando pra v2.3.2.
tem um pull request na Baileys pra arrumar isso, https://github.com/WhiskeySockets/Baileys/pull/1826
talvez corrijam, vou dar um downgrade pra 2.3.2 pois depois dela só vieram bugs pra mim
Tenho este problema e não uso nada de grupos @luizcw . Acabei de voltar para v2.3.2.
tem um pull request na Baileys pra arrumar isso, WhiskeySockets/Baileys#1826
talvez corrijam, vou dar um downgrade pra 2.3.2 pois depois dela só surgiram bugs pra mim
e ai deu certo?
A 2.3.2 tem problemas sérios com whatsapp baileys. Muitas vezes não entrega ou recebe mensagens, volta e meia tem que reiniciar o container, mas pelo menos não está com o problema do @lid no contato chatwoot. Estou preparando migração pra outra plataforma, meu uso da evolution é basicamente pra manter whatsapp meta e qrcode conectados ao chatwoot, e no momento, só dor de cabeça. Vejo bastante comentários positivos a respeito da uazapi.
Tenho este problema e não uso nada de grupos @luizcw . Acabei de voltar para v2.3.2.
tem um pull request na Baileys pra arrumar isso, WhiskeySockets/Baileys#1826 talvez corrijam, vou dar um downgrade pra 2.3.2 pois depois dela só surgiram bugs pra mim
e ai deu certo?
pior que não kkkk ficou com o mesmo problema, acho que foi algum update no Whatsapp em si que quebrou... tentei com 2.3.2 e mesmos sintomas. como eu tenho várias instâncias e vários grupos em cada uma delas, tá dando um problemão danado, mensagens sendo duplicadas, vários contatos salvo em duplicidade (com jid e lid), está uma quebradeira......
Alguém conseguiu resolver esse problema? Estou utilizando junto com chatwoot e n8n e não consegui nenhuma alternativa para transformar esse @ lid para @ s.whatsapp.net
up mesmo problema aqui
upppp
Mesmo problema aqui.
Same with v2.3.6.
I was 1.8.2, then 2.3.5 and now 2.3.6 same problem.
Usando 2.3.6 continua com o erro do @lid, duplicando as mensagens no chatwoot
alguem resolvou essa questao?
Parece que esse repositório foi totalmente abandonado e o foco totalmente voltado para v3.
Eu resolvi. Fiz backup do banco. Uso docker, usei a 4.4.0 do chatwoot e a 2.3.6 do evolution.
Não dá pra fazer upgrade da v3 pra v4 pq muda muita coisa no banco, e são coisas que não tinham na minha versão do postgres.
Tive que subir a versão 14 do postgres tb.
Depois restaurei no banco novo o backup.
Ficou lindo.
Baileys v7: Resolvendo Duplicação de Contatos e Conversas Separadas
Após migrar para Baileys v7, enfrentamos duplicação de contatos e conversas separadas. As causas foram: (1) identificadores LID (@lid) não preservados, (2) números não normalizados, e (3) uso incorreto de JID ao enviar mensagens.
Solução Técnica:
-
Preservar JID/LID Original:
- Ao receber mensagem, salvar msg.key.remoteJid completo (pode ser @lid ou @s.whatsapp.net) em um campo separado (ex: whatsappJid)
- Nunca sobrescrever LID com JID tradicional - LID é mais preciso
-
Normalizar Números Brasileiros:
- Extrair número de msg.key.remoteJidAlt primeiro (se disponível e não for @lid)
- Se não disponível, usar msg.key.remoteJid (se for @s.whatsapp.net tradicional)
- Normalizar: adicionar "55" se faltar, adicionar "9" para celulares (55 + DDD + 8 dígitos → 55 + DDD + 9 + 8 dígitos)
- Salvar número normalizado separado do whatsappJid
-
Buscar Contato por JID Primeiro:
- Ao criar/atualizar contato, buscar primeiro pelo whatsappJid salvo
- Se não encontrar, buscar pelo número normalizado
- Isso evita duplicados quando o mesmo contato aparece com formatos diferentes
-
Enviar Mensagem com JID Correto:
- Ao enviar via wbot.sendMessage(), usar o whatsappJid salvo (LID ou JID original)
- Não construir JID a partir do número - isso causa conversas separadas para contatos com LID
- Fallback: construir JID apenas se whatsappJid não existir (contatos antigos)
-
Tratar Mensagens fromMe:
- Quando msg.key.fromMe === true (confirmação de envio), buscar contato existente pelo número
- Usar whatsappJid e name do contato existente em vez de criar novo
- Isso evita criar contatos com nome = número
-
API/Webhook - Buscar Antes de Criar:
- Ao receber número via API, normalizar primeiro
- Buscar contato existente pelo número normalizado ANTES de criar
- Se encontrar, usar whatsappJid e name existentes
Pontos Críticos:
- LID (@lid) é mais preciso que JID tradicional - sempre preservar
- remoteJidAlt pode ter número mais confiável que remoteJid
- Número normalizado é para busca/compatibilidade, whatsappJid é para comunicação com Baileys
- Sempre usar whatsappJid salvo ao enviar mensagens, nunca construir a partir do número
Isso garante que todas as mensagens do mesmo usuário fiquem em uma única conversa, mesmo com LID.
A versão 2.3.7 resolveu pro problema