Comportamento de falha em trabalhos VersionCheck

Desculpe se esta não é a categoria correta para isso.

Estou avaliando o Discourse e o Job VersionCheck está falhando em meu ambiente.

Notei que os jobs falhos estão se acumulando dentro do Sidekiq e provavelmente serão movidos para a seção “dead” após as 25 tentativas padrão (conforme https://www.rubydoc.info/gems/sidekiq/Sidekiq/JobRetry).

Eu sei que preciso investigar o que está causando a falha, mas o ponto aqui é: faz sentido manter esses jobs lá? Não seria melhor simplesmente descartar as verificações de versão falhas e esperar a próxima execução do job?

Neste momento, tenho mais de 80 jobs VersionCheck aguardando para tentar novamente e, para mim, isso parece um desperdício de recursos (provavelmente pouco, mas ainda assim um desperdício)…

Pelo que verifiquei, adicionar sidekiq_options retry: false a app/jobs/scheduled/version_check.rb resolveria isso.

Estou perdendo alguma coisa?

Como você instalou? Há algum motivo para acreditar que você tem problemas de rede? RAM?

Você pode estar certo, mas como você é a única pessoa a relatar isso (pelo menos até agora), isso não entrou na lista de otimizações. Faz sentido simplesmente deixar falhar após uma tentativa, eu acho.

Quando foi a última vez que você atualizou?

Houve um problema com o trabalho de verificação de versão algumas semanas atrás (por volta do final de outubro), mas já foi corrigido. Se você atualizar no terminal (./launcher rebuild app), deve funcionar.

1 curtida

Estou usando a instalação padrão do docker dentro de uma instância ec2.

Estou em um ambiente corporativo, então há muitos firewalls, proxies e scanners de segurança entre a instância e a internet. Nos logs, vejo um erro “Job exception: Connection reset by peer - SSL_connect (Errno::ECONNRESET)”, então provavelmente algum firewall está negando a solicitação em algum momento… Ainda estou entendendo como o discourse faz essas verificações de versão para que eu possa reproduzi-las manualmente e obter mais detalhes.

Entendo totalmente isso. No passado, trabalhei com o gitlab e vi muitos problemas onde filas completas do sidekiq causavam degradação de desempenho e outros comportamentos estranhos, então toda vez que vejo algo assim, meus alarmes disparam. :smile:

1 curtida

Estou na versão 2.8.0.beta9 (959923d3cf)

Sim… A atualização no terminal ou via GUI está funcionando bem (executo semanalmente). O único problema neste caso é que a tela principal do administrador não mostra a versão mais recente e sempre diz que estou executando uma versão desatualizada.

Então você definitivamente deve executar uma atualização pela linha de comando

O Discourse acessará a internet para tarefas como verificar atualizações de versão, buscar avatares de usuários, baixar imagens remotas para armazenamento local e oneboxing em geral. Se a instância for desconectada da internet, haverá alguns problemas, de fato.

1 curtida

Sim! Estou fazendo isso toda semana até encontrar uma solução.

Tive que desistir do oneboxing exatamente por esse motivo. Por enquanto, não posso permitir acesso total à internet para este servidor.
github.com/* já está permitido, mas provavelmente este trabalho de verificação de versão usa outra URL para fazer isso.

1 curtida

O que eu faria seria apenas desativar SiteSetting.version_checks, remover o plugin discourse_docker e fazer atualizações pela linha de comando.

Mas, aqui, se você conseguir acessar https://api.discourse.org/api, então provavelmente está tudo bem.

1 curtida

Obrigado pela informação! Funcionou quando permiti o acesso a https://api.discourse.org/api/version_check

1 curtida