Bug nel ripristino dei file SVG dal backup

Quando si tenta di ripristinare un backup (in un ambiente multisito, ma ciò non sembra influire, vedi sotto), si verifica quanto segue:

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

Inizialmente pensavo che si trattasse di un problema legato esclusivamente all’ambiente multisito, ma l’errore si verifica anche in un ambiente non multisito.

La cosa curiosa è che, in quel momento, gli upload non venivano nemmeno estratti (EDIT: a quel punto). Quel file di upload specifico è comunque incluso nell’archivio.

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

Versione del dump del database originale v20190130013015

Ho quindi estratto manualmente gli upload (nella directory default) e ho rieseguito il ripristino, che è andato a buon fine.

A quel punto ho notato… gli upload vengono estratti DOPO db:migrate, ma db:migrate esegue SiteIconManager.ensure_optimized!, che richiede che i file siano già presenti…

Quindi ci sono due problemi:

  • SiteIconManager.ensure_optimized! viene eseguito prima che le immagini siano state estratte; (in realtà viene eseguito due volte: una prima e un’altra dopo l’estrazione degli upload)
  • si aspetta che i file siano nella directory default perché il remap non è ancora stato eseguito.

In questo caso specifico, l’errore è grave perché il codice per un upload SVG segue un percorso diverso. Per altri upload sembra fallire in modo silenzioso.

A proposito, osservando il codice, sembra che si possa aggirare il problema impostando SKIP_POST_DEPLOYMENT_MIGRATIONS=1, poiché ciò salta l’ottimizzazione delle immagini durante db:migrate, ma quando l’ho provato non ha funzionato.

6 Mi Piace

Chi dovrebbe dare un’occhiata a questo, @sam?

1 Mi Piace

Sembra abbastanza semplice:

E

L’ultima persona che ha sperimentato questo flusso è stata @gerhard

@RGJ, se vuoi accelerare la diagnosi qui, potresti creare un database vuoto con un singolo SVG che fallisce il ripristino; questo ci renderà molto più facile testare.

7 Mi Piace

Ti ho inviato un messaggio privato con un file di backup il più possibile snello che non viene ripristinato.

È necessario un file SVG “piccolo” sull’icona del sito o sul manifesto per innescare il bug.

A proposito, ho appena scoperto che SKIP_POST_DEPLOYMENT_MIGRATIONS viene esplicitamente reimpostato, ecco perché non ha funzionato come soluzione temporanea.

5 Mi Piace

Grazie per aver segnalato il problema e fornito un file di esempio. È stato risolto.

6 Mi Piace