Erro ao enviar mensgem com chatwoot - Timed out reading data

Welcome!

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

What did you do?

Ao tentar enviar algumas mensagens no chatwoot, integrado com a evo api, ocasionalmente as mensagens apresentam o erro "Timed out reading data". Apesar de apresentar o erro, se visualizar a mesma conversa no whatsapp, a mensagem foi enviada.
Alguém com o mesmo problema? Alguma resolução?

What did you expect?

Que enviassem as mensagens corretamente

What did you observe instead of what you expected?

Algumas mensagens dão erro ao serem enviadas no chatwoot, mas visualizando pelo whatsapp normal elas estão lá

Screenshots/Videos

Which version of the API are you using?

ultima versão

What is your environment?

Windows

Other environment specifications

No response

If applicable, paste the log output

No response

Additional Notes

No response

Isso nem erro da Evo é
Acontece que o webhook do Chatwoot tem um timeout de 5s pra não ficar segurando a req por muito tempo
Se a Evo demorar mais de 5s pra devolver a resposta ele vai entender como erro de Timeout no Chatwoot

Você pode seguir por duas abordagens

Tentar aumentar a velocidade de resposta da Evo ( Otimizações de forma geral )
Aumentar o timeout padrão do Chatwoot de 5s, pra 10s, por exemplo. Já inibi muito esse log.

De qualquer forma, a mensagem vai ser enviada.
Se realmente der algum erro ele vai informar no notas.

Isso nem erro da Evo é Acontece que o webhook do Chatwoot tem um timeout de 5s pra não ficar segurando a req por muito tempo Se a Evo demorar mais de 5s pra devolver a resposta ele vai entender como erro de Timeout no Chatwoot

Você pode seguir por duas abordagens
1. Tentar aumentar a velocidade de resposta da Evo ( Otimizações de forma geral )

Alguma dica de configuração?

2. Aumentar o timeout padrão do Chatwoot de 5s, pra 10s, por exemplo. Já inibi muito esse log.

Bom, eu aumentei o timeout de 5s pra 45 e continua a mesma coisa, acredito que o problema esteja em outro lugar.

/app # grep -nE 'timeout:\s*[0-9]+' lib/webhooks/trigger.rb
29: timeout: 45

De qualquer forma, a mensagem vai ser enviada. Se realmente der algum erro ele vai informar no notas.

Apesar de enviada, ainda é um inconveniente ter que abrir o whatsapp web ou pegar o celular pra confirmar se a mensagem foi realmente enviada. No meu ambiente eu não me importo de fazer isso vez ou outra, porém pra implementar pra clientes não fica muito legal não, precisava achar uma solução

Mesma situacao por aqui, usando as versoes:
Chatwoot: 4.5.1
Evolution: 2.3.1 (via imagem docker evoapicloud/evolution-api:v2.3.1)

Compartiharei com comunidade qualquer solucao que encontre aqui.

Tentando reproduzir o erro, descobri que:
Essa mensagem de time out, sempre aparece quando tento enviar mais de um anexo (imagem, arquivo...) em uma mesma mensagem pelo chatwoot, bem como em: #895 (comment)

Verifica se teu DNS é cloudflare ou google. Eu tive problemas com esses servidores, onde apontavam pros servidores da meta fora do Brasil, e com muito lag, timeouts e perda de pacotes. A solução no meu caso, foi adicionar configuração pra web.whatsapp.com e graph.facebook.com apontarem pra IPs da meta que resolvem no RJ e SP.

Verifica se teu DNS é cloudflare ou google. Eu tive problemas com esses servidores, onde apontavam pros servidores da meta fora do Brasil, e com muito lag, timeouts e perda de pacotes. A solução no meu caso, foi adicionar configuração pra web.whatsapp.com e graph.facebook.com apontarem pra IPs da meta que resolvem no RJ e SP.

Voce identificou um vilao oculto, a porcari@ do Smart Tiered Caching Topology (que de smart nao tem nada) estava pegando uma conexao do DC em SP e roteando para a Alemanha para entao trazer novamente a SP. Latencia lá em cima. Desabillitei e a conexao da minha origem ao Cloudflare voltou a ser SP. Monitorando para ver como se comporta agora.

@andrekutianski

@andrekutianski se tiver novidades dá um grito por favor! Isso me irrita demais...

E quando ta rodando em cliente, e daí o cliente vai descascando sua vida... Até explicar essa situação, tá complicado.

@guhweb

@guhweb qual sua versao do Chatwoot?

Com a desativacao da opcao do CF a latencia caiu 50%, mas ainda o timeout esta ocorrendo! Notei alguns erros intermitentes no Evolution neste meio tempo:

[Evolution API]    v2.3.1  163   -  Tue Sep 02 2025 16:39:32     ERROR   [unhandledRejection]  [object]   
PrismaClientKnownRequestError:
Invalid `prisma.$executeRawUnsafe()` invocation:
Raw query failed. Code: `42P10`. Message: `ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification`
at Xn.handleRequestError (/evolution/node_modules/@prisma/client/runtime/library.js:121:7459)
at Xn.handleAndLogRequestError (/evolution/node_modules/@prisma/client/runtime/library.js:121:6784)
at Xn.request (/evolution/node_modules/@prisma/client/runtime/library.js:121:6491)
at async l (/evolution/node_modules/@prisma/client/runtime/library.js:130:9812)
at async $s.addLabel (/evolution/dist/main.js:250:4045)
at async labels.association (/evolution/dist/main.js:227:35072) {
code: 'P2010',
meta: {
code: '42P10',
message: 'ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification'
},
clientVersion: '6.11.1'
}
[Evolution API]    v2.3.1  163   -  Tue Sep 02 2025 16:40:31     ERROR   [ChatwootImport]  [string]  Error on getExistingSourceIds: Error: getaddrinfo ENOTFOUND host

@andrekutianski

@andrekutianski meu chatwoot está na versão 4.3.0 e a evolution api está na 2.3.0.

@andrekutianski meu chatwoot está na versão 4.3.0 e a evolution api está na 2.3.0.

Posso descartar questao de versao do Chatwoot entao? Pois parece que a situacao nao esta afetando uma em especifico.

Por aqui continua na mesma, e já rola nos últimos 7 dias.

Cara, na real isso rola de boas versões atrás... Tanto o chatwoot quando da evolution... Falaram de aumentar o timeout da requisição, mas não sei ao certo onde fazer isso! Me parece que é num .env.... Eu vou ter que dar uma fuçada!

Alguma alma caridosa pode confirmar se são esses parâmetros que devem ser alterados?

Isso nem erro da Evo é Acontece que o webhook do Chatwoot tem um timeout de 5s pra não ficar segurando a req por muito tempo Se a Evo demorar mais de 5s pra devolver a resposta ele vai entender como erro de Timeout no Chatwoot
Você pode seguir por duas abordagens
1. Tentar aumentar a velocidade de resposta da Evo ( Otimizações de forma geral )
Alguma dica de configuração?
2. Aumentar o timeout padrão do Chatwoot de 5s, pra 10s, por exemplo. Já inibi muito esse log.
Bom, eu aumentei o timeout de 5s pra 45 e continua a mesma coisa, acredito que o problema esteja em outro lugar.

/app # grep -nE 'timeout:\s*[0-9]+' lib/webhooks/trigger.rb 29: timeout: 45

De qualquer forma, a mensagem vai ser enviada. Se realmente der algum erro ele vai informar no notas.

Apesar de enviada, ainda é um inconveniente ter que abrir o whatsapp web ou pegar o celular pra confirmar se a mensagem foi realmente enviada. No meu ambiente eu não me importo de fazer isso vez ou outra, porém pra implementar pra clientes não fica muito legal não, precisava achar uma solução

Resposta:

45 s de timeout é realmente fora do padrão — não é algo recomendado. E provavelmente você nem configurou isso corretamente como variável de ambiente no Chatwoot.

Além disso, não há necessidade de abrir o WhatsApp Web para confirmar o envio. Conforme mencionei, caso ocorra algum erro, você será notificado automaticamente via notas, de forma assíncrona pela própria Evo.

O ideal é:

Não exagerar no timeout — valores muito altos podem causar instabilidade.

Verificar a configuração correta do timeout no Chatwoot, preferencialmente criar uma ENV, pq não existe.

Confiar no sistema de notas da Evo para acompanhar erros e confirmações de envio, sem precisar de intervenções manuais.

Aqui foi resolvido alterando a variável ACTIVE_STORAGE_SERVICE para o valor local

Opa, foi realmente resolvido? nenhuma ocorrência ainda?

Pra quem ta com esse problema, e usa o chatwoot por docker, testem essa solução:
(se usa o chatwoot nativo, só altere no arquivo que vou mencionar)

1- Na mesma pasta onde está o docker compose do chatwoot, crie o arquivo "trigger.rb" e adicione o conteudo:
class Webhooks::Trigger
  SUPPORTED_ERROR_HANDLE_EVENTS = %w[message_created message_updated].freeze

  def initialize(url, payload, webhook_type)
    @url = url
    @payload = payload
    @webhook_type = webhook_type
  end

  def self.execute(url, payload, webhook_type)
    new(url, payload, webhook_type).execute
  end

  def execute
    perform_request
  rescue StandardError => e
    handle_error(e)
    Rails.logger.warn "Exception: Invalid webhook URL #{@url} : #{e.message}"
  end

  private

  def perform_request
    RestClient::Request.execute(
      method: :post,
      url: @url,
      payload: @payload.to_json,
      headers: { content_type: :json, accept: :json },
      timeout: 25     # <----------- ALTERE AQUI
    )
  end

  def handle_error(error)
    return unless should_handle_error?
    return unless message

    update_message_status(error)
  end

  def should_handle_error?
    @webhook_type == :api_inbox_webhook && SUPPORTED_ERROR_HANDLE_EVENTS.include?(@payload[:event])
  end

  def update_message_status(error)
    Messages::StatusUpdateService.new(message, 'failed', error.message).perform
  end

  def message
    return if message_id.blank?

    @message ||= Message.find_by(id: message_id)
  end

  def message_id
    @payload[:id]
  end
end
2- No docker compose do chatwoot, localize o serviço do sidekiq e adicione o volume:
    volumes:
      - ./trigger.rb:/app/lib/webhooks/trigger.rb
3 - Reinicie os serviços com docker compose down e docker compose up -d

4 - Confirme se o valor foi alterado no container. No meu caso, o serviço do sidekiq está com o nome de "chatwoot-sidekiq-1", mas o nome pode ser confirmado utilizando o comando docker ps

Entre no container com:
docker exec -it **chatwoot-sidekiq-1** sh

Confirme o valor alterado com:
grep -nE 'timeout:\s*[0-9]+' lib/webhooks/trigger.rb

Se retornou o valor que você colocou no arquivo trigger.rb, deu certo. Eu testei valores aqui e 25s foi o tempo que melhor se adaptou ao meu cenário, mas alterem conforme necessário

Eai Cayman, resolveu pra você?

Eai Cayman, resolveu pra você?

sim, tentou reproduzir?

@CaymanS0

@CaymanS0 ta, então em resumo, seu ambiente agora está quaaaase 100%... Exceto por essa situação quando são duas imagens, confere?

Dá um resumo rápido de como está o seu ambiente atual: Está tudo na última versão, com a alteração do timeout pra 15s (no trigger.rb). Confere?

Eai Cayman, resolveu pra você?

sim, tentou reproduzir?

Sim, fizemos de tudo e mais um pouco, mexemos no Sidekiq, proxy e mais, mas nada adiantou...

Notamos sim uma diminuída, mas atualmente estávamos testando com 8 vendedores, com mais de 10 instâncias na Evolution e o erro de Time out reading data ocorria. Além disso sempre tivemos de problema com: O cliente manda a foto, no WhatsApp aparece porém não no Chatwoot.

Fizemos e refizemos a instalação do Chatwoot + Evo do zero, ajustamos isso e aquilo mas não resolveu.

Enfrentado o meus problema aqui, dá erro no chatwoot, porém no WhatsApp ela envia...

Enfrentado o meus problema aqui, dá erro no chatwoot, porém no WhatsApp ela envia...

Sim, o erro era somente no frontend, pois era enviado...

Desistimos de usar Chatwoot e Evolution por causa desses problemas

Enfrentado o meus problema aqui, dá erro no chatwoot, porém no WhatsApp ela envia...

Sim, o erro era somente no frontend, pois era enviado...

Desistimos de usar Chatwoot e Evolution por causa desses problemas

E estão usando o que?

Enfrentado o meus problema aqui, dá erro no chatwoot, porém no WhatsApp ela envia...

Sim, o erro era somente no frontend, pois era enviado...
Desistimos de usar Chatwoot e Evolution por causa desses problemas

E estão usando o que?

Como a gente não conseguiu resolver de jeito nenhum, fomos pro atendechat (whaticket basicamente), porém fizemos algumas alterações a mais lá, como integração direta com API Oficial (por isso tínhamos ido pro Chatwoot anteriormente)

Até o momento 100%

@CaymanS0 ta, então em resumo, seu ambiente agora está quaaaase 100%... Exceto por essa situação quando são duas imagens, confere?

Dá um resumo rápido de como está o seu ambiente atual: Está tudo na última versão, com a alteração do timeout pra 15s (no trigger.rb). Confere?

Na verdade está 100% ja, após as correções que fiz e documentei aqui nos comentarios. Essas mesmas alterações com timeout de 15s foram implementadas em um cliente, onde percebi que 15s não foram o suficiente (provavelmente porque ele tem um fluxo de conversas muito maior que o meu) vou aumentar o timeout dele semana que vem e observar. Antes de tudo isso, atualizei a evolution e o chatwoot para a ultima versão, e eu utilizo o nginx proxy manager como proxy reverso.

Uma consideração importante a ressaltar é que antes de atualizar a evo eu utilizava a imagem "atendai" da evo (uma antiga que disponibilizaram aqui), não me recordo bem como era o nome. Troquei para a "evoapicloud/evolution-api" e deixei na ultima versão

Eai Cayman, resolveu pra você?

sim, tentou reproduzir?

Sim, fizemos de tudo e mais um pouco, mexemos no Sidekiq, proxy e mais, mas nada adiantou...

Notamos sim uma diminuída, mas atualmente estávamos testando com 8 vendedores, com mais de 10 instâncias na Evolution e o erro de Time out reading data ocorria. Além disso sempre tivemos de problema com: O cliente manda a foto, no WhatsApp aparece porém não no Chatwoot.

Fizemos e refizemos a instalação do Chatwoot + Evo do zero, ajustamos isso e aquilo mas não resolveu.

Sei que você ja parou de usar a evo, mas caso volte:
Tentou aumentar mais do que 15s o timeout? Conferiu se alterou mesmo após reiniciar os containers?
E esse problema de imagens no chatwoot eu também ja tive, se não me engano corrigi mexendo nas permissões do diretório que armazena as imagens
Se você usa um proxy reverso, é valido também testar a comunicação entre a evo e o chatwoot através da url de ambos. No meu caso, eu tive que adicionar no docker-compose o parametro "extra hosts" com a url dos serviços e o ip do proxy reverso. Exemplo:

    extra_hosts:
      - "evolution.dominio.com.br:192.168.x.x"

Isso ajudou na comunicação entre os serviços pra mim, não sei se é a melhor prática ou o jeito certo de resolver os problemas, mas foi o que funcionou

@CaymanS0

@CaymanS0 você resolveu? eu estou usando VPS contabo, sem cloud dns ainda estou nessa com 3 clientes basicamente reclamando disso, envia no whats mas no front do chatwoot não resolve :(

@edersonmartinsv

@edersonmartinsv sim, não aconteceu mais aqui. Qual o problema com o seu especificamente?

@edersonmartinsv sim, não aconteceu mais aqui. Qual o problema com o seu especificamente?

aqui ainda continua com o problema

Hello guy please check this solution #1874 (comment). It worked for me

Navigation Menu

Repository navigation

Erro ao enviar mensgem com chatwoot - Timed out reading data #1887

Welcome!

What did you do?

What did you expect?

What did you observe instead of what you expected?

Screenshots/Videos

Which version of the API are you using?

What is your environment?

Other environment specifications

If applicable, paste the log output

Additional Notes

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Erro ao enviar mensgem com chatwoot - Timed out reading data #1887

Description

Welcome!

What did you do?

What did you expect?

What did you observe instead of what you expected?

Screenshots/Videos

Which version of the API are you using?

What is your environment?

Other environment specifications

If applicable, paste the log output

Additional Notes

Activity

p3dr0574 commented on Aug 30, 2025

CaymanS0 commented on Sep 1, 2025

andrekutianski commented on Sep 1, 2025

CaymanS0 commented on Sep 2, 2025

danielvieirabrwo commented on Sep 2, 2025

andrekutianski commented on Sep 2, 2025

guhweb commented on Sep 2, 2025

andrekutianski commented on Sep 2, 2025

guhweb commented on Sep 2, 2025

andrekutianski commented on Sep 2, 2025

guhweb commented on Sep 2, 2025

guhweb commented on Sep 2, 2025

p3dr0574 commented on Sep 3, 2025

11 remaining items

danielrvieira commented on Sep 10, 2025

danielrvieira commented on Sep 10, 2025

CaymanS0 commented on Sep 10, 2025

guhweb commented on Sep 10, 2025

danielrvieira commented on Sep 11, 2025

gabizera commented on Sep 18, 2025

danielrvieira commented on Sep 18, 2025

gabizera commented on Sep 18, 2025

danielrvieira commented on Sep 18, 2025

CaymanS0 commented on Sep 19, 2025

CaymanS0 commented on Sep 19, 2025

edersonmartinsv commented on Oct 5, 2025

CaymanS0 commented on Oct 10, 2025

edersonmartinsv commented on Oct 11, 2025

vargasjona commented on Dec 12, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions