Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#211 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 5 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
api, backend

Línea de trabajo

Start by tracing handling of events.StreamError, the ignoreStatus filter, and status@broadcast message or ack processing. Use the supplied logs and repeated Status ID as the reproduction context. Done means status media does not trigger a fatal restart when ignoreStatus=true, and the stream error or status ack is handled without repeated delivery.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug
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

Lenguaje dominante
Go
Estrellas
918
Forks
488
Merge medio
5 min
PR fusionados (30 d)
1

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de evolution-foundation/evolution-go

Todos los issues de evolution-foundation/evolution-go

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.