Welcome!

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

What did you do?

Analisei o mecanismo de webhooks do Evolution API e notei que existem limitações na forma como as retentativas e timeouts são gerenciados:

1. O timeout da requisição não é configurável, o que causa problemas quando webhooks demoram mais que o esperado para responder.
2. O sistema de retentativas tem valores fixos (10 tentativas com 30 segundos entre cada uma), sem possibilidade de configuração.
3. O intervalo entre retentativas é fixo, não há backoff exponencial para evitar sobrecarregar servidores quando eles estão instáveis.
4. Não há distinção entre erros recuperáveis e não-recuperáveis - o sistema tenta novamente mesmo em casos onde isso não faz sentido (como erro 404 ou 401).
5. Bug crítico: O sistema está enviando o mesmo webhook múltiplas vezes (até 10 vezes) mesmo quando o servidor de destino está disponível e respondendo com sucesso. Isso causa duplicação de dados e processamento desnecessário no servidor de destino.

Isso causa problemas de estabilidade e desempenho em ambientes de produção com alto volume de webhooks ou quando os servidores de destino estão sob carga.

What did you expect?

Um sistema robusto de webhooks que:

• Permita configurar o timeout de requisições via variáveis de ambiente
• Permita ajustar os parâmetros de retentativa (máximo de tentativas, intervalo inicial, etc.)
• Implemente backoff exponencial para aumentar gradualmente o tempo entre tentativas
• Detecte e não tente novamente em casos de erros permanentes (códigos HTTP como 400, 401, 403, etc.)
• Forneça logs detalhados sobre as tentativas e falhas
• Mais importante: Reconheça corretamente respostas bem-sucedidas e não faça retentativas quando o webhook foi entregue com sucesso

What did you observe instead of what you expected?

• Timeout fixo sem possibilidade de configuração
• Retentativas constantes mesmo para erros permanentes, causando tráfego desnecessário
• Intervalo fixo entre tentativas, sem crescimento exponencial
• Possíveis problemas de "thundering herd" quando muitos webhooks falham ao mesmo tempo
• Logs insuficientes para diagnóstico de falhas em webhooks
• Bug crítico: Mesmo com o servidor de callback saudável e respondendo com códigos 200, o sistema continua reenviando o mesmo webhook até 10 vezes. Isso gera duplicação de dados e carga desnecessária tanto na nossa API quanto no servidor de destino.

Isso causa:

1. Requisições ficando penduradas por longos períodos quando o servidor de destino está lento
2. Recursos desperdiçados em tentativas que nunca serão bem-sucedidas (como enviar para URLs que retornam 404)
3. Possível sobrecarga em servidores de destino devido ao padrão de retentativas sem backoff
4. Processamento redundante e múltiplo de eventos que deveriam ser processados apenas uma vez

Screenshots/Videos

No response

Which version of the API are you using?

2.2.3

What is your environment?

Docker

Other environment specifications

No response

If applicable, paste the log output

No response

Additional Notes

Gostaria de ajudar com a implementação de uma solução que permita configurar timeout e retentativas via variáveis de ambiente, para tornar o sistema de webhooks mais robusto e configurável. Já implementei uma solução inicial que adiciona:

1. Configuração de timeout via .env
2. Sistema de retentativas com backoff exponencial
3. Tratamento diferenciado para erros permanentes vs. temporários
4. Logs melhorados para diagnóstico
5. Correção do bug que causa duplicação de webhooks

Seria possível avaliar esta melhoria? Posso submeter um PR com as alterações e testes.