Avatares personalizados "desapareceram" após atualizar para 3.3.0beta1

Olá,

Recentemente atualizei nossos fóruns de teste para a versão 3.3.0beta1. O fórum de teste é basicamente uma cópia um pouco desatualizada (em termos de conteúdo) de nossos fóruns principais. Nós o usamos para testar atualizações e novos recursos. Ele usa a mesma conexão Amazon S3 para uploads que os fóruns principais.

Após atualizar o sistema operacional do host para o Ubuntu 24.04 LTS mais recente e atualizar os fóruns para a versão 3.3.0beta1, todos os avatares personalizados desapareceram e a imagem de cabeça branca/cinza é exibida em vez deles.

Após analisar os logs, encontrei mensagens como:

Não foi possível encontrar o arquivo na loja localizado em url: //ourbucket.s3.dualstack.eu-central-1.amazonaws.com/original/3X/6/9/69ca9110f27d91561axyz52a9cd9485a970fe9.jpeg

Embora, na verdade, a imagem exista nesse URL e funcione muito bem. Tentei usar o wget para baixar o arquivo do servidor para ver se havia algum problema de DNS ou outras coisas que pudessem impedir o proxy de avatar local de obtê-lo - mas isso também não é o caso.

Alguma ideia do que pode estar acontecendo aqui?

Parece que isso não está acontecendo apenas nos fóruns de teste, mas também nos fóruns ativos os avatares estão desaparecendo aos poucos com os mesmos erros no log.

Eu me pergunto se o fórum de teste está limpando coisas que ele não espera no bucket s3, mas você diz que as coisas estão no bucket, então não é isso. Talvez restaurar um banco de dados para teste e olhar o que está no modelo de uploads.

O problema é que a mensagem de erro no log indica que ele não consegue carregar uma determinada imagem, mas essa imagem exata está disponível. Portanto, algo está impedindo o proxy de fórum/avatar de buscar a imagem, suponho.

1 curtida

Acabei de carregar um novo avatar no servidor de teste (executando 3.3.0beta1). Ele foi carregado, apareceu na pré-visualização, mas falhou ao carregar novamente.

/var/www/discourse/app/models/optimized_image.rb:81:in `block in create_for' 
/var/www/discourse/app/models/optimized_image.rb:19:in `block (2 levels) in lock' 
/var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize' 
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize' 
/var/www/discourse/app/models/optimized_image.rb:19:in `block in lock' 
/var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize' 
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize' 
/var/www/discourse/app/models/optimized_image.rb:18:in `lock' 
/var/www/discourse/app/models/optimized_image.rb:73:in `create_for' 
/var/www/discourse/app/models/upload.rb:130:in `get_optimized_image' 
/var/www/discourse/app/controllers/user_avatars_controller.rb:218:in `get_optimized_image' 
/var/www/discourse/app/controllers/user_avatars_controller.rb:136:in `show_in_site' 
/var/www/discourse/app/controllers/user_avatars_controller.rb:89:in `block (2 levels) in show' 
/var/www/discourse/lib/hijack.rb:64:in `instance_eval' 
/var/www/discourse/lib/hijack.rb:64:in `block in hijack' 
concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:911:in `callback_on_resolution' 
concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:797:in `call_callback' 
concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:803:in `call_callbacks' 
concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:692:in `resolve_with' 
concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/promises.rb:1325:in `resolve' 
/var/www/discourse/lib/scheduler/defer.rb:115:in `block in do_work' 
rails_multisite-5.0.1/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
rails_multisite-5.0.1/lib/rails_multisite/connection_management.rb:21:in `with_connection'
/var/www/discourse/lib/scheduler/defer.rb:109:in `do_work' 
/var/www/discourse/lib/scheduler/defer.rb:97:in `block (2 levels) in start_thread' 

Isso é do log.

A mensagem de log para isso é:

Não foi possível encontrar o arquivo no armazenamento localizado no URL: //ourbucket.s3.dualstack.eu-central-1.amazonaws.com/original/3X/0/2/02832e36e27bbad791fda46e2290df31e5ee2dda.jpeg

(modifiquei o URL para que não funcione, embora o real funcione)

‘block in hijack’ é o que me intriga.

Estamos rodando atrás do Cloudflare no sistema principal. O sistema de teste está em “Apenas DNS”, portanto, obviamente, não filtrado pelo Cloudflare. Tivemos alguns problemas recentemente com bots no site principal, com os quais brincamos bastante com os filtros do Cloudflare.

Mas então, por que buscar de um URL amazonaws.com seria um problema para isso - e novamente o site de teste não está rodando pelo Cloudflare.

Estou um pouco confuso no momento, para ser honesto.

Estou realmente preso nisso. Parece afetar tanto os fóruns ao vivo quanto os de teste - o ao vivo ainda está em uma versão mais antiga e o problema nem parece ter começado com a atualização, mas apareceu há alguns dias sem que nenhuma mudança notável acontecesse.

Então, o que acontece é que o Discourse carrega novos avatares personalizados corretamente para o S3, coloca ACLs neles, pelo que vejo, corretamente, e os arquivos também são publicamente acessíveis através do URL que o Discourse tenta usar para puxá-los para o proxy de avatar - ainda assim falha em fazê-lo (veja o rastreamento de pilha acima).

Alguém com bom conhecimento sobre como o proxy de avatar funciona tem alguma ideia ou pode extrair algo desse rastreamento de pilha?

Eu fiz um wget do URL da imagem a partir dos servidores e todos eles funcionam bem - então não há nada lá que deva bloquear o acesso a esse URL.

E você consegue obtê-los do seu navegador?

Ah sim, desculpe se isso não ficou claro. Eu consigo acessá-los do navegador (então presumi que estivessem publicamente disponíveis) e também do servidor (para excluir que seja algum tipo de problema que o servidor está tendo para obtê-los. Na verdade, é apenas o discourse que não os está obtendo por algum motivo (veja o rastreamento da pilha acima).

1 curtida

Você encontrou uma solução para o seu problema? Estamos tendo exatamente o mesmo problema na versão 3.2.1. O bucket tem todo o acesso público bloqueado, no entanto, ainda estava funcionando através de URLs pré-assinadas. Agora estou tendo exatamente o mesmo erro:

Não foi possível encontrar o arquivo na loja localizado em url: