Actualizar / Reconstruir Discourse a la última versión rompe irreversiblemente el sitio web

[RyouTakeshi]

Hola, hemos estado atascados con un error muy desagradable que ha roto todo nuestro sitio web sin una solución aparente. Hemos intentado de todo, desde reconstruir hasta eliminar/agregar complementos sin éxito. Tenemos una copia de seguridad funcional de hace un par de meses, pero parece que cualquier intento de reconstruir esto con una versión más reciente simplemente rompe el sitio.

El mensaje principal que se muestra dice:

Oops
El software que impulsa este foro de discusión encontró un problema inesperado. Lamentamos las molestias.

La información detallada sobre el error se registró y se generó una notificación automática. Le echaremos un vistazo.

No se requiere ninguna acción adicional. Sin embargo, si la condición de error persiste, puede proporcionar detalles adicionales, incluidos los pasos para reproducir el error, publicando un tema de discusión en la categoría de comentarios del sitio.

Este es un mensaje de error genérico de Discourse que no produce resultados reales al solucionar problemas. Al revisar los registros de nuestro docker, pude encontrar esto:

Completed 500 Internal Server Error in 152ms (ActiveRecord: 0.0ms | Allocations: 17980)
ActionView::Template::Error (undefined method `[]' for nil:NilClass)
lib/svg_sprite/svg_sprite.rb:502:in `block in custom_icons'
lib/svg_sprite/svg_sprite.rb:500:in `each'
lib/svg_sprite/svg_sprite.rb:500:in `custom_icons'
lib/svg_sprite/svg_sprite.rb:275:in `block in all_icons'
lib/distributed_cache.rb:25:in `defer_get_set'
lib/svg_sprite/svg_sprite.rb:517:in `get_set_cache'
lib/svg_sprite/svg_sprite.rb:268:in `all_icons'
lib/svg_sprite/svg_sprite.rb:337:in `bundle'
lib/svg_sprite/svg_sprite.rb:285:in `block in version'
lib/distributed_cache.rb:25:in `defer_get_set'
lib/svg_sprite/svg_sprite.rb:517:in `get_set_cache'
lib/svg_sprite/svg_sprite.rb:284:in `version'
lib/svg_sprite/svg_sprite.rb:290:in `path'
app/helpers/application_helper.rb:586:in `client_side_setup_data'
app/views/layouts/application.html.erb:61
lib/topic_list_responder.rb:13:in `block (2 levels) in respond_with_list'
lib/topic_list_responder.rb:9:in `respond_with_list'
app/controllers/list_controller.rb:103:in `block (2 levels) in <class:ListController>'
app/controllers/application_controller.rb:387:in `block in with_resolved_locale'
app/controllers/application_controller.rb:387:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:71:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:356:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:23:in `call'
lib/middleware/request_tracker.rb:198:in `call'

Así que, naturalmente, pensé que podría solucionar el problema simplemente implementando un try/catch en la línea 501 donde ocurre el error. Este es el método en cuestión:

  def self.custom_icons(theme_id)
    # Automatically register icons in sprites added via themes or plugins
    icons = []
    custom_svg_sprites(theme_id).each do |item|
      begin
        svg_file = Nokogiri::XML(item[:sprite])
        svg_file.css('symbol').each do |sym|
          icons << sym.attributes['id'].value if sym.attributes['id'].present?
        end
      rescue Exception => e
        puts e
      end
    end
    icons
  end

Si bien esto restaura la funcionalidad del sitio, desafortunadamente lo hace sin cargar ningún icono o imagen en todo el sitio web, por lo que en última instancia esto no soluciona nada.

Estamos utilizando los siguientes complementos:

          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-bbcode.git
          - git clone https://github.com/discourse/discourse-follow.git
          - git clone https://github.com/discourse/discourse-user-notes.git

Por lo que recuerdo, hemos utilizado algunos complementos como discourse-follow antes de que fueran compatibles oficialmente, por lo que tal vez degradarlos rompió algo en el proceso.

La versión original antes de la actualización era 2.8.0.beta2, ahora estamos en 2.9.0.beta1.

He intentado casi todo lo que se me ocurre, no estaba seguro de si debía publicar aquí porque siento que este es un error demasiado genérico para que alguien pueda ayudar, pero si alguien tiene alguna idea de lo que está causando esto, agradecería la ayuda.

[IAmGav (Gavin Perch)]

Podría ser un problema de Postgres, donde Postgres está intentando actualizar de la versión 10 a la 13.

Revisa los registros para ver si encuentras algo relacionado con Postgres.

[RyouTakeshi]

@IAmGav

Podría ser un problema de Postgres, donde Postgres está intentando actualizar a la versión 13 desde la 10.

Revisa los registros para ver si encuentras algo relacionado con Postgres.

¿Te refieres a los registros contenidos en /shared/standalone/log/rails? Porque no mencionan nada relacionado con postgres. En cuanto a los registros contenidos en /shared/standalone/log/var-log/postgres, alrededor del momento del error, 19:51:08, hay una solicitud que no parece fuera de lo común. Ningún error ni nada que parezca fallar. Y alrededor del momento de la actualización, no creo que eso se registre aquí.

¿Tienes algo en particular que pueda buscar?

[IAmGav (Gavin Perch)]

asegúrate de que tu apt-get update | apt-get upgrade esté actualizado
y luego ejecuta ./launcher rebuild app

busca errores o mira en /var/discourse/shared/standalone/log/rails

[RyouTakeshi]

@IAmGav

asegúrate de que tu apt-get update | apt-get upgrade esté actualizado
y luego ejecuta ./launcher rebuild app

comprueba si hay errores o mira en /var/discourse/shared/standalone/log/rails

He actualizado tanto apt-get update como apt-get upgrade, he realizado una reconstrucción completa y, lamentablemente, me encuentro con los mismos errores. Por lo que puedo ver, nada ha cambiado.

[jomaxro (Joshua Rosenfeld)]

Algunas preguntas:

1. ¿Se completa la reconstrucción sin errores?
2. ¿Ha intentado cargar el sitio en modo seguro?
3. ¿Puede compartir la URL del sitio para que podamos echarle un vistazo?

[RyouTakeshi]

@jomaxro

Algunas preguntas:

1. ¿La reconstrucción se completa sin errores?
2. ¿Has intentado cargar el sitio en modo seguro?
3. ¿Puedes compartir la URL del sitio para que podamos echar un vistazo?

1. Sí, la reconstrucción se completa sin errores.
2. Sí, y al igual que cuando soluciono el error mencionado anteriormente, arranca el sitio web en una especie de modo “sin iconos / imágenes” donde nada se carga.
3. Sí y no, el sitio contiene contenido explícito y tendré que preguntar si la gente se siente cómoda con que lo comparta.

Mientras tanto, he descubierto algo más: al navegar por el sitio web en modo seguro, noté que DiscoTOC lanza un error. Al deshabilitarlo, el sitio web vuelve a funcionar normalmente sin necesidad de modo seguro, sin embargo, los iconos/imágenes todavía no se cargan correctamente.

Todas las imágenes están lanzando 404 en la consola, la mayoría de los iconos como el favicon están lanzando 500.
Naturalmente, todo funcionaba bien antes.

[RyouTakeshi]

Para añadir a esto, ¿podría ser que la reconstrucción haya borrado de alguna manera todas las referencias de imágenes de la base de datos?

[RyouTakeshi]

Para mantener a todos actualizados, he probado varias sugerencias de diferentes hilos, pero solo por nombrar dos:

Images lost in backup/restore, change of domain, can't upload new

My solution was FTP move them (crude but it worked). Not 100% sure why. At first I moved only the optimized images and it didn’t fix the problem, but when I moved all the images it resolved my issue. Thanks for the more detail instruction on how to FTP into my two Discourses. The uploads file was about 125 MB on the old Discourse, 60 MB on the new one. So I copied the old one to my laptop’s Desktop. Then I copied its contents, folder-by-folder, to the new Discourse, skipping any duplications. …

Avatars lost after restore. How to get them back?

@Iceman This is mostly FYI, and maybe it is TMI, but it might help you in some small way gain additional insight into some of the interesting things we experience running three containers (two web application and one data container) at the same time (and how it also effects user avatars). It’s is very interesting (and very cool, in my view), how the Redis / Sidekiq job scheduler works when they are running in parallel, but only one “active on the user web side”: Hope you find this short disc…

Ninguna de las sugerencias ayudó, rake posts:rebake, rake posts:missing_uploads y rake uploads:recover_from_tombstone no funcionaron, desafortunadamente. También he revisado el panel de sidekiq, pero eso tampoco está restaurando nada.

A quien tenga alguna idea de cómo restaurar las imágenes ahora perdidas, le agradecería que me la hiciera saber.

[RyouTakeshi]

Después de muchos intentos y errores, logré restaurar las imágenes con éxito, así que consideraré este problema resuelto.

[pfaffman (Jay Pfaffman)]

¿Había algo que desearas saber al principio?

[RyouTakeshi]

Quizás haber revisado el sitio web en modo seguro desde el principio habría ayudado. También debo admitir que solo estuve involucrado en la restauración del sitio después de que ya se había hecho algo de trabajo en él, resultó que las imágenes estaban en una carpeta separada de respaldo y solo tuvieron que trasladarse.

[pfaffman (Jay Pfaffman)]

@RyouTakeshi

resultó que las imágenes estaban en una carpeta separada de copia de seguridad y solo tuvieron que trasladarse.

¡Difícil de adivinar para cualquiera! Me alegro de que lo hayas resuelto.