Ao enviar msg pela api infinit e baileys - avatares somem, a lista de chats pisca e tem alguns contatos poluindo a lista de chats #8

New Issue

2026-05-08T05:03:22+02:00

ruicesar commented

2026-05-08 05:03:22 +02:00

Ao enviar msg pela api infinit e baileys - avatares somem, a lista de chats pisca e tem alguns contatos poluindo a lista de chats.
responda sempre em portugues

![image.png](/attachments/0c62c388-c95c-4e63-bd69-2a19305b61c6) Ao enviar msg pela api infinit e baileys - avatares somem, a lista de chats pisca e tem alguns contatos poluindo a lista de chats. responda sempre em portugues

image.png

403 KiB

ruicesar added this to the Erro de avatares e contatos na lista de chats - clube67.com/inbox project 2026-05-08 05:03:22 +02:00

ruicesar commented

2026-05-08 05:08:32 +02:00

Corrigido com sucesso absoluto! 🚀

🔍 O Problema Diagnosticado

Analisamos a rota de envio de mensagens pela API REST (/api/instances/:instanceId/send) e descobrimos o motivo de todos os sintomas relatados:

"Avatares somem": Ao enviar uma mensagem via API, o backend enviava o evento Socket.IO chat:upsert com contact: null (comentário de placeholder no código indicava que o Baileys deveria popular isso depois). Isso sobrescrevia o estado do contato no frontend e sumia com o avatar.
"A lista de chats pisca": Como a UI recebia o chat atualizado com o contato como null, ela re-renderizava tudo repentinamente limpando os dados visuais do contato, e logo em seguida tentava re-buscar as informações, gerando uma piscada visual incômoda.
"Contatos poluindo a lista": Sem as informações do contato associadas no evento chat:upsert, a inbox exibia a entrada do chat usando o número/JID puro e cru do telefone sem nome amigável ou foto, parecendo que a lista estava sendo poluída por contatos fantasmas/desconhecidos.

🛠️ A Solução Aplicada

Garantia de Contato no Banco: No fluxo de envio da rota /send, agora o contato do destinatário é criado/atualizado (upsert) antes de persistir o chat.
Vínculo Correto: Associamos o contactId do contato criado diretamente ao chat criado/atualizado.
Payload Socket.IO Completo: Atualizamos o evento chat:upsert para resolver e enviar os dados completos do contato em tempo real (nome resolvido displayName, telefone formatado, avatarUrl, scoreReputacao e flagRestricao), idêntico ao comportamento dos chats criados nativamente.

O container foi reconstruído com as alterações aplicadas e já está rodando saudável de forma estável! ✨

Corrigido com sucesso absoluto! 🚀 ### 🔍 O Problema Diagnosticado Analisamos a rota de envio de mensagens pela API REST (`/api/instances/:instanceId/send`) e descobrimos o motivo de todos os sintomas relatados: * **"Avatares somem":** Ao enviar uma mensagem via API, o backend enviava o evento Socket.IO `chat:upsert` com `contact: null` (comentário de placeholder no código indicava que o Baileys deveria popular isso depois). Isso sobrescrevia o estado do contato no frontend e sumia com o avatar. * **"A lista de chats pisca":** Como a UI recebia o chat atualizado com o contato como `null`, ela re-renderizava tudo repentinamente limpando os dados visuais do contato, e logo em seguida tentava re-buscar as informações, gerando uma piscada visual incômoda. * **"Contatos poluindo a lista":** Sem as informações do contato associadas no evento `chat:upsert`, a inbox exibia a entrada do chat usando o número/JID puro e cru do telefone sem nome amigável ou foto, parecendo que a lista estava sendo poluída por contatos fantasmas/desconhecidos. ### 🛠️ A Solução Aplicada 1. **Garantia de Contato no Banco:** No fluxo de envio da rota `/send`, agora o contato do destinatário é criado/atualizado (`upsert`) antes de persistir o chat. 2. **Vínculo Correto:** Associamos o `contactId` do contato criado diretamente ao chat criado/atualizado. 3. **Payload Socket.IO Completo:** Atualizamos o evento `chat:upsert` para resolver e enviar os dados completos do contato em tempo real (nome resolvido `displayName`, telefone formatado, `avatarUrl`, `scoreReputacao` e `flagRestricao`), idêntico ao comportamento dos chats criados nativamente. O container foi reconstruído com as alterações aplicadas e já está rodando saudável de forma estável! ✨

ruicesar closed this issue

2026-05-08 05:08:43 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ruicesar/clube67_newwhats.local#8