Repository navigation
@lid no Chatwoot #2003
Description
Activity
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: '5511999998888@s.whatsapp.net', //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.4Mesma 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 resolverTenho 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, WhiskeySockets/Baileys#1826
talvez corrijam, vou dar um downgrade pra 2.3.2 pois depois dela só vieram bugs pra mim
Reacted by Daniel Vieira LeiteTenho 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 mime 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
Reacted by Andrey Lima Ramos and Approvedalguem resolvou essa questao?
Reacted by Andrey Lima Ramos and ApprovedParece 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
Reacted by Rodrigo RobledoAlguém conseguiu resolver esse problema, estou com ele travando minha operação aqui!
Closing as duplicate of #1872 —
@lidhandling meta-issue (cross-cuts Chatwoot in this case).See #1872 for tracked
@lidsymptoms and #2014 for the Chatwoot umbrella.