Bug lors de la restauration de fichiers SVG depuis une sauvegarde

Contribuer Bug
1

Lors de la tentative de restauration d’une sauvegarde (vers un multisite, mais cela ne semble pas importer, voir ci-dessous), voici ce qui se produit :

Migration de la base de données...
EXCEPTION : lib/discourse.rb:57:in `exec' : Échec de la migration de la base de données.
rake aborted!
Errno::ENOENT : Aucun fichier ou répertoire du type @ 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

Au début, je pensais qu’il s’agissait purement d’un problème lié au multisite, mais l’échec se produit également sur un site non multisite.

Le plus drôle, c’est que les uploads n’étaient même pas encore extraits à ce moment-là (EDIT : à ce moment précis). Pourtant, ce fichier spécifique est bien inclus dans l’archive.

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

Version du dump de base de données original : v20190130013015

J’ai ensuite extrait manuellement les uploads (dans default) puis relancé la restauration, qui a réussi.

Et c’est là que j’ai vu… les uploads sont extraits APRÈS db:migrate, mais db:migrate exécute SiteIconManager.ensure_optimized!, qui exige que les fichiers soient déjà présents…

Il y a donc deux problèmes :

  • SiteIconManager.ensure_optimized! s’exécute avant que les images ne soient extraites ; (en réalité, elle s’exécute deux fois – une fois de plus après l’extraction des uploads)
  • elle attend les fichiers dans default car la réaffectation n’a pas encore été exécutée.

Dans ce cas précis, l’échec est critique car le code relatif à un upload SVG emprunte un chemin d’exécution différent. Pour d’autres uploads, il semble échouer silencieusement.

Au passage, en examinant le code, il semble que cela puisse être contourné en utilisant SKIP_POST_DEPLOYMENT_MIGRATIONS=1, car cela saute l’optimisation des images lors de db:migrate, mais cela n’a pas fonctionné lorsque je l’ai essayé.

6 « J'aime »
2

Qui devrait consulter celui-ci, @sam ?

1 « J'aime »
3

Cela semble assez simple :

Et

La dernière personne à avoir expérimenté ce flux était @gerhard.

@RGJ, si vous souhaitez accélérer le diagnostic ici, vous pourriez créer une base de données vide contenant un seul fichier SVG qui échoue lors de la restauration ; cela nous rendra les tests beaucoup plus faciles.

7 « J'aime »
5

Je vous ai envoyé un MP contenant un fichier de sauvegarde aussi léger que possible qui ne se restaure pas.

Il faut un fichier SVG « petit » sur le favicon ou le manifest pour que le bug se déclenche.

Au fait, je viens de découvrir que SKIP_POST_DEPLOYMENT_MIGRATIONS est explicitement réinitialisé, c’est pourquoi cela n’a pas fonctionné comme solution de contournement.

5 « J'aime »
6

Merci d’avoir signalé le problème et fourni un fichier exemple. Cela a été corrigé.

6 « J'aime »