Instância cai em ciclo após stream:error <ack class="status" type="media"/> (Status de mídia), mesmo com ignoreStatus=true #211

Welcome!

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

What did you do?

Olá, time Evolution GO!

Somos o Zapdo (zapdo.com.br), uma plataforma brasileira de pedidos para delivery que usa o Evolution GO como conexão principal do WhatsApp das lojas. Começamos a usar o projeto há pouco tempo, gostamos muito e queremos contribuir para que ele fique cada vez mais estável. Por isso, deixamos abaixo tudo o que coletamos sobre um comportamento que observamos em produção. Se precisarem de mais registros ou de algum teste do nosso lado, é só pedir.

Parece ser o mesmo caso relatado na issue #185 (a origem é a mesma). No nosso ambiente, porém, a instância reconecta sozinha em cerca de 4 s, e a queda volta em ciclo.

Ambiente
Imagem: evoapicloud/evolution-go:latest (criada em 2026-09-30T03:44:41Z)
Docker com Traefik na frente e Postgres em container separado (max_connections=100; 57 conexões em uso: 51 ociosas, 1 ativa)
VPS com 4 GB de RAM (871 MB usados, sem swap) e disco em 7%. Nenhum reinício de container e nenhum OOM.
2 instâncias ativas, ambas com ignoreGroups=true e ignoreStatus=true, sem proxy
Webhook HTTP com as subscriptions MESSAGE SEND_MESSAGE READ_RECEIPT PRESENCE HISTORY_SYNC CHAT_PRESENCE CALL CONNECTION LABEL CONTACT GROUP NEWSLETTER QRCODE BUTTON_CLICK PICTURE USER_ABOUT
disconnect_reason vazio nas duas instâncias
O que acontece
Um contato do número publica um Status com mídia (vídeo/imagem).
O servidor do WhatsApp responde com stream:error, que o Evolution registra como evento não tratado.
O Evolution detecta a desconexão e reinicia a instância. A reconexão leva cerca de 4 s.
Depois de cerca de 50 minutos, o mesmo Status (mesmo id) volta a gerar o erro e a instância cai de novo.
Na instância afetada foram 17 quedas em 24 h. A outra instância, no mesmo servidor e com a mesma configuração, teve 0 ocorrências desse erro. A diferença entre elas é só o volume de Status recebidos: a afetada recebe dezenas por hora, incluindo um vídeo de 96 MB.

Registros (instância dc37071f-3ee4-4305-ab15-f32b61d1772d)
2026/10/01 19:26:47 [WARN] Unhandled event *events.StreamError: &{Code: Raw:stream:error</stream:error>}
2026/10/01 19:26:47 [INFO] Disconnected detected, restarting instance
2026/10/01 20:16:51 [WARN] Unhandled event *events.StreamError: &{Code: Raw:stream:error</stream:error>}
2026/10/01 20:16:51 [INFO] Disconnected detected, restarting instance
2026/10/01 21:06:54 [WARN] Unhandled event *events.StreamError: &{Code: Raw:stream:error</stream:error>}
2026/10/01 21:06:54 [INFO] Disconnected detected, restarting instance
2026/10/01 22:37:01 [WARN] Unhandled event *events.StreamError: &{Code: Raw:stream:error</stream:error>}
2026/10/01 22:37:01 [INFO] Disconnected detected, restarting instance
O id 3EB0354FFD61697A73B009 aparece três vezes, sempre com cerca de 50 minutos de intervalo.

Logo antes das quedas, os registros mostram muitos Status chegando, por exemplo:

2026/10/01 20:06:34 [INFO] ===== MESSAGE RECEIVED ===== ID: 3A073E1ACB1B47C9A6AABEFB716B7058, From: status@broadcast, Type: media, Size: 96812914 bytes
O que esperávamos
Com ignoreStatus=true, que Status (status@broadcast) não afetassem a sessão. Na prática, o filtro só evita o envio ao webhook, mas o recebimento e o ack continuam acontecendo.
Que um stream:error do tipo ack class="status" fosse tratado sem derrubar a conexão, ou que o ack do Status fosse confirmado ou descartado corretamente, para o WhatsApp não reentregá-lo.
Sugestões (com todo respeito ao conhecimento do time)
Tratar *events.StreamError com como erro não fatal.
Quando ignoreStatus=true, enviar o ack/receipt de status@broadcast sem processar nem baixar a mídia.
Registrar o disconnect_reason com o conteúdo bruto do stream error, para facilitar o diagnóstico.
Referências
Issue #185: mesmo stream:error <ack class="status" ...>, no caso dela sem reconexão
Issues #109, #112 e #118: conexões Postgres acumuladas em reconexões (acompanhamos nosso pool por esse motivo)
Obrigado pelo trabalho no projeto! Estamos à disposição para testar uma build com correção.

Equipe Zapdo

What did you expect?

Com ignoreStatus=true, que Status (status@broadcast) não afetassem a sessão. Na prática, o filtro só evita o envio ao webhook, mas o recebimento e o ack continuam acontecendo. Também esperávamos que um stream:error do tipo ack class="status" fosse tratado sem derrubar a conexão — ou que o ack do Status fosse confirmado/descartado corretamente, para o WhatsApp não reentregá-lo.

What did you observe instead of what you expected?

Um contato do número publica um Status com mídia (vídeo/imagem) e o servidor do WhatsApp responde com stream:error , que o Evolution registra como evento não tratado (*events.StreamError). O Evolution detecta a desconexão e reinicia a instância; a reconexão leva cerca de 4 s. Em produção, a instância caiu 17× em 24 h, em ciclos de ~50 min, com o mesmo id de Status reentregue a cada queda. Outra instância no mesmo servidor e mesma configuração teve 0 ocorrências — a diferença é só o volume de Status: a afetada recebe dezenas por hora, incluindo um vídeo de 96 MB.

Screenshots/Videos

No response

Which version are you using?

latest (imagem evoapicloud/evolution-go:latest, criada em 2026-09-30)

What is your environment?

Linux

If applicable, paste the log output

Docker com Traefik na frente e Postgres em container separado (max_connections=100; 57 conexões em uso: 51 ociosas, 1 ativa). VPS com 4 GB de RAM (871 MB usados, sem swap), disco em 7%. Nenhum reinício de container, nenhum OOM. 2 instâncias ativas com ignoreGroups=true e ignoreStatus=true, sem proxy. Webhook HTTP com subscriptions MESSAGE SEND_MESSAGE READ_RECEIPT PRESENCE HISTORY_SYNC CHAT_PRESENCE CALL CONNECTION LABEL CONTACT GROUP NEWSLETTER QRCODE BUTTON_CLICK PICTURE USER_ABOUT. disconnect_reason vazio nas duas instâncias.

Additional Notes

No response