Recientemente actualicé nuestros foros de prueba a la versión 3.3.0beta1. El foro de prueba es básicamente una copia un tanto desactualizada (en cuanto a contenido) de nuestros foros en vivo. Lo usamos para probar actualizaciones y nuevas funciones. Utiliza la misma conexión de Amazon S3 para las cargas que los foros en vivo.
Después de actualizar el sistema operativo anfitrión a la última versión de Ubuntu 24.04 LTS y actualizar los foros a la 3.3.0beta1, todos los avatares personalizados han desaparecido y se muestra la cabeza blanca/gris en su lugar.
Después de revisar los registros, encuentro mensajes como:
No se pudo encontrar el archivo en el almacén ubicado en la URL: //ourbucket.s3.dualstack.eu-central-1.amazonaws.com/original/3X/6/9/69ca9110f27d91561axyz52a9cd9485a970fe9.jpeg
Aunque, de hecho, la imagen existe en esa URL y funciona bastante bien. Intenté descargar el archivo desde el servidor usando wget para ver si había algún problema de DNS u otras cosas que pudieran impedir que el proxy de avatar local lo obtuviera, pero tampoco es el caso.
Parece que esto no solo está sucediendo en los foros de prueba, sino que también en los foros en vivo los avatares desaparecen poco a poco con los mismos errores en el registro.
Me pregunto si el foro de prueba está limpiando cosas que no espera en el bucket s3, pero dices que las cosas están en el bucket, así que no es eso. Quizás restaurar una base de datos a pruebas y ver qué hay en el modelo de subidas.
El problema es que el mensaje de error en el registro indica que no puede cargar una imagen determinada, pero esa imagen exacta está disponible. Así que supongo que hay algo que impide que el proxy de avatares/foros obtenga la imagen.
Acabo de subir una nueva imagen de avatar en el servidor de pruebas (ejecutando 3.3.0beta1). Se subió, apareció en la vista previa, pero luego falló al cargarse de nuevo.
/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'
Esto es del log.
El mensaje del log para eso es:
No se pudo encontrar el archivo en el almacén ubicado en la URL: //ourbucket.s3.dualstack.eu-central-1.amazonaws.com/original/3X/0/2/02832e36e27bbad791fda46e2290df31e5ee2dda.jpeg
(modifiqué la URL para que no funcione, aunque la real sí funciona)
‘block in hijack’ es lo que me desconcierta.
Estamos ejecutando detrás de Cloudflare en el sistema principal. El sistema de pruebas está en “Solo DNS”, por lo que obviamente no está filtrado a través de Cloudflare. Tuvimos algunos problemas últimamente con bots en el sitio principal, con los que jugamos bastante con los filtros de Cloudflare.
Pero entonces, ¿por qué la obtención de una URL de amazonaws.com sería un problema para eso, y de nuevo, el sitio de prueba no pasa por Cloudflare en absoluto?
Para ser honesto, estoy un poco confundido en este momento.
Estoy realmente atascado en eso. Parece afectar tanto a los foros en vivo como a los de prueba; el en vivo todavía está en una versión anterior y el problema ni siquiera parece haber comenzado con la actualización, sino que apareció hace unos días sin que ocurrieran cambios notables.
Entonces, lo que sucede es que Discourse carga correctamente los nuevos avatares personalizados en S3, les aplica ACLs, según puedo ver, correctamente y los archivos también son públicamente accesibles a través de la URL que Discourse intenta usar para incorporarlos al proxy de avatares; aún así, no lo logra (ver el rastreo de la pila anterior).
¿Alguien con buenos conocimientos sobre cómo funciona el proxy de avatares tiene alguna idea o puede extraer algo de ese rastreo de la pila?
Hice un wget de la URL de la imagen desde los servidores y todas funcionan bien, así que no hay nada allí que deba bloquear el acceso a esa URL.
Ah, sí, disculpa si no quedó claro. Puedo acceder a ellos desde el navegador (así que asumí que estaban disponibles públicamente) y también desde el servidor (para descartar que sea algún tipo de problema que el servidor tenga para obtenerlos. Realmente es solo Discourse el que no los obtiene por alguna razón (ver el rastreo de la pila anterior).
¿Encontraste una solución a tu problema? Estamos teniendo exactamente el mismo problema en la versión 3.2.1. El bucket tiene todo el acceso público bloqueado, sin embargo, todavía funcionaba a través de URLs pre-firmadas. Ahora estoy teniendo exactamente el mismo error:
No se pudo encontrar el archivo en el almacén ubicado en la url: