Error al restaurar archivos SVG desde la copia de seguridad

Contribuir Error
1

Al intentar restaurar una copia de seguridad (en un entorno multisitio, pero eso no parece importar, ver más abajo), ocurre lo siguiente:

Migrating the database...
EXCEPTION: lib/discourse.rb:57:in `exec': Failed to migrate database.
rake aborted!
Errno::ENOENT: No such file or directory @ rb_sysopen - /var/www/discourse/public/uploads/default/original/2X/7/7be997f9f48c034ddf5d4eb95d2ea7416f010241.svg
/var/www/discourse/app/models/optimized_image.rb:87:in `block in create_for'
/var/www/discourse/app/models/optimized_image.rb:24:in `block (2 levels) in lock'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/app/models/optimized_image.rb:23:in `block in lock'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/app/models/optimized_image.rb:22:in `lock'
/var/www/discourse/app/models/optimized_image.rb:59:in `create_for'
/var/www/discourse/lib/site_icon_manager.rb:28:in `block in ensure_optimized!'
/var/www/discourse/lib/site_icon_manager.rb:24:in `each'
/var/www/discourse/lib/site_icon_manager.rb:24:in `ensure_optimized!'
/var/www/discourse/lib/tasks/db.rake:83:in `block in <top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/ruby_executable_hooks:24:in `eval'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/ruby_executable_hooks:24:in `<main>'
Tasks: TOP => db:migrate

Al principio pensé que se trataba exclusivamente de un problema multisitio, pero también falla en un entorno no multisitio.

Lo curioso es que ni siquiera estaba extrayendo las subidas (EDIT: en ese momento). Sin embargo, esa subida específica está incluida en el archivo.

tar tvf public/backups/default/redacted-forum-2020-03-02-165725-v20190130013015.tar.gz |grep 7be997f9f48c034ddf5d4eb95d2ea7416f010241
-rw-r--r-- daemon/daemon     3074 2019-05-27 08:21 uploads/default/original/2X/7/7be997f9f48c034ddf5d4eb95d2ea7416f010241.svg

Versión del volcado de base de datos original v20190130013015

Luego extraje las subidas manualmente (en default) y ejecuté la restauración nuevamente, lo cual tuvo éxito.

Y entonces lo vi… las subidas se extraen DESPUÉS de db:migrate, pero db:migrate está ejecutando SiteIconManager.ensure_optimized!, lo que requiere que los archivos ya estén presentes…

Así que hay dos problemas:

  • SiteIconManager.ensure_optimized! se ejecuta antes de que las imágenes hayan sido extraídas; (de hecho, se ejecuta dos veces: una vez más después de que las subidas hayan sido extraídas)
  • Espera los archivos en default porque el remapeo aún no se ha ejecutado.

En este caso específico, falla de manera crítica porque el código para una subida de SVG sigue una ruta de código diferente. Para otras subidas, parece fallar en silencio.

Por cierto, al revisar el código, parece que esto podría evitarse usando SKIP_POST_DEPLOYMENT_MIGRATIONS=1, ya que eso omite la optimización de imágenes durante db:migrate, pero eso no funcionó cuando lo intenté.

6 Me gusta
2

¿Quién debería ver esto, @sam?

1 me gusta
3

Parece bastante sencillo:

Y

La última persona que experimentó con este flujo fue @gerhard

@RGJ, si te gustaría acelerar el diagnóstico aquí, quizás podrías crear una base de datos vacía con un solo SVG que falle al restaurar; eso nos facilitará mucho las pruebas.

7 Me gusta
5

Te envié un mensaje privado con un archivo de respaldo lo más ligero posible que no se restaura.

Requiere un archivo SVG “pequeño” en el favicon o en el manifiesto para que se active el error.

Por cierto, acabo de descubrir que SKIP_POST_DEPLOYMENT_MIGRATIONS se restablece explícitamente, por lo que eso no funcionó como solución alternativa.

5 Me gusta
6

Gracias por reportar el problema y proporcionar un archivo de ejemplo. Ya ha sido corregido.

6 Me gusta