[BUG] Evento presence.update nunca é emitido na v2.3.7 com endereçamento Multi-Device LID

[gf-nexwise]

O que você fez?

Configurei a Evolution API v2.3.7 com WEBHOOK_EVENTS_PRESENCE_UPDATE=true
e um WEBHOOK_GLOBAL_URL apontando para um backend interno. Outras
configurações de webhook (mensagens, conexão, etc.) funcionam normalmente.

Para testar o evento de presença:

1. Subi a Evolution v2.3.7 em Kubernetes com as envs:

   - name: WEBHOOK_EVENTS_PRESENCE_UPDATE
     value: "true"
   - name: WEBHOOK_GLOBAL_URL
     value: "<URL do webhook interno>"

2. Criei uma instância e conectei via QR code em uma conta WhatsApp.
3. De outra conta WhatsApp — com todas as sessões linkadas removidas
   (apenas o celular conectado) — abri a conversa com a instância e:
   • Comecei a digitar (sem enviar) para gerar presence: composing
   • Enviei mensagens de teste

Comparei os logs do pod e o endpoint do webhook para ver se algum evento
de presença chegava em alguma das duas pontas.

O que você esperava?

Quando o contato remoto começa a digitar / gravar áudio / fica online /
unavailable, a Evolution deveria:

• Logar o evento de presença vindo do Baileys (nível VERBOSE/DEBUG)
• Enviar um payload presence.update para o webhook configurado (e/ou
  subscribers de WebSocket)

Referências às issues
#467 e
#1617
descrevem o mesmo sintoma em versões anteriores (1.6.x e 2.2.x/2.3.0).
A #1617 foi fechada sem fix oficial; o workaround sugerido pela comunidade
lá (desconectar todas as sessões secundárias do remetente) não
resolve na v2.3.7 no nosso caso (testamos).

O que você observou ao invés do que esperava?

Todos os outros eventos da mesma instância chegam normalmente:

• messages.upsert chega e é logado completo ✅
• messages.update (DELIVERY_ACK, status: 2) chega normalmente ✅
• OnWhatsappCache resolve LID ↔ phone corretamente ✅
• Updating contact (DEBUG do ChannelStartupService) é logado ✅
• Nenhum evento presence.update aparece no log do pod, independente
  de quantas mensagens são trocadas ou de como está a topologia de
  sessões do remetente ❌
• O endpoint do webhook nunca recebe evento de presença ❌

Fizemos grep no buffer completo de logs do pod pelas seguintes strings —
zero ocorrências em uma janela de 1h+ com conversa ativa:
presence, composing, available, unavailable, paused,
presenceUpdate, handlePresenceUpdate, sendPresence.

Todas as mensagens recebidas chegam com addressingMode: 'lid'. Nossa
suspeita é que isso seja o diferencial em relação aos reports antigos
onde presence funcionava: o endereçamento clássico
(@s.whatsapp.net) pode não ser afetado, mas o LID novo do Multi-Device
parece bloquear o evento de presence em algum ponto do pipeline
(Baileys → Evolution → webhook).

Qual versão da API você está usando?

2.3.7 (imagem evoapicloud/evolution-api:v2.3.7)

Qual é o seu ambiente?

Docker (Kubernetes 1.33)

Outras especificações do ambiente

• SO do host: Amazon Linux 2023 (worker node Kubernetes)
• Banco de dados: PostgreSQL 15
• Tipo de conexão: Baileys (Multi-Device, addressingMode: lid)
• Deploy: Pod único em Kubernetes
• Device do remetente no teste: Apenas WhatsApp iOS (todos os linked
  devices removidos antes do teste)
• Webhook target: Backend HTTP interno, alcançável do pod

Se aplicável, cole a saída do log

Amostra do buffer de log de ~1h de conversa ativa. Duas mensagens de
teste foram enviadas pelo contato após remover explicitamente todas as
sessões do WhatsApp Web. Ambas chegam corretamente. Nenhum evento de
presença é logado antes, durante ou depois.

[Evolution API] v2.3.7 LOG [ChannelStartupService] Update not read messages <REDACTED>@lid
{
  key: {
    remoteJid: '<REDACTED>@s.whatsapp.net',
    remoteJidAlt: '<REDACTED>@s.whatsapp.net',
    fromMe: false,
    id: '<message-id>',
    addressingMode: 'lid'
  },
  pushName: '<REDACTED>',
  status: 'DELIVERY_ACK',
  message: { conversation: '<test text>', ... },
  messageType: 'conversation',
  source: 'ios'
}
[Evolution API] v2.3.7 VERBOSE [OnWhatsappCache] [saveOnWhatsappCache] Register exists for [<REDACTED>] => <REDACTED>@s.whatsapp.net
[Evolution API] v2.3.7 DEBUG [ChannelStartupService] Updating contact: { "id": "<REDACTED>@lid", "notify": "<REDACTED>" }

Um segundo messages.upsert do mesmo contato poucos segundos depois é
logado da mesma forma — também sem nenhum evento de presença antes,
durante ou depois.

Notas adicionais

• O webhook target recebe messages.upsert e outros eventos normalmente
  durante a mesma janela — ou seja, conectividade OK e o pipeline de
  webhook funciona para outros tipos de evento. Só presence é silencioso.
• A conversa tem addressingMode: 'lid' em todos os eventos. Suspeitamos
  que isso seja o diferencial em relação a reports antigos onde presence
  funcionava com endereçamento clássico @s.whatsapp.net.
• Issues relacionadas:
  • #1617
    — fechada sem fix real; o workaround de "sessão exclusiva" não se
    aplica na v2.3.7.
  • #467
    — mesmo sintoma na v1.6.1; fechada como "resolvida" mas o comentário
    que marcou como resolvido tem 5 👎.
  • #2469
    — problema oposto (always online) na v2.3.7.

Disponível para fornecer mais logs ou testar um patch.