Falsi positivi su "i post non vengono rimappati al nuovo URL di caricamento S3"

Stavo migrando la nostra istanza Discourse da un server a un altro e mi sono imbattuto in un problema interessante…

Utilizziamo S3 per archiviare gli upload dal forum. Li abbiamo abilitati diversi anni fa, quindi non è qualcosa che abbiamo introdotto in questa migrazione.
Dopo aver risolto un paio di altri problemi, sono riuscito a importare il backup. Tuttavia, è fallito in un passaggio relativo a S3 con il seguente errore:

Aggiornamento degli URL nel database...
Rimozione delle vecchie immagini ottimizzate...
Segnalazione di tutti i post contenenti lightbox per il rebake...
72038 post sono stati segnalati per un rebake
ECCEZIONE: 257 post non sono stati rimappati al nuovo URL di upload S3. Migrazione S3 fallita per il db 'default'.

Dopo aver approfondito un po’, sono riuscito a risalire al problema a questa riga:

Quindi, sono andato nella console rails e sono stato in grado di replicare le query con quanto segue:

discourse(prod)> SiteSetting.cdn_path("/uploads/#{@current_db}/original").sub(/https?:/, "")
=> "/uploads//original"
discourse(prod)> RailsMultisite::ConnectionManagement.current_db
=> "default"
discourse(prod)> cdn_path = SiteSetting.cdn_path("/uploads/default/original").sub(/https?:/, "")
=> "/uploads/default/original"
discourse(prod)> Post.where("cooked LIKE '%#{cdn_path}%'")
=> ...

Quindi, sono andato a quei post particolari, ed erano parte dei Performance Reports (lo screenshot è di dopo che ho eseguito uno script di ricerca e sostituzione):

Apparentemente, quel controllo recupera qualsiasi post contenente /uploads/default/original nel campo cooked, nonostante potrebbe non essere un asset legittimo. In questo caso, /uploads/default/original è stato utilizzato come “testo normale”, quindi non è stato perso durante il processo di migrazione.

Non sono sicuro se questo sia previsto?
Grazie!

Ho visto problemi simili con i post elaborati, credo.

Forse puoi fare un ripristino solo del database e quindi salta quei controlli.

Questo è quello che proverei dopo.

Sono stato in grado di ripristinarlo completamente semplicemente sostituendo il testo in quei post in modo che non corrisponda al filtro. Non è stato un problema per me, ma lo segnalo nel caso in cui qualcuno affronti lo stesso problema, dato che forse vale la pena risolverlo in Discourse.

2 Mi Piace

Sì. Forse il codice non dovrebbe controllare i post elaborati.

1 Mi Piace

Sono abbastanza sicuro di aver riscontrato anche questo nel tentativo di ripristinare un backup e ho creato il backup con “includi caricamenti” DISABILITATO. C’è qualcos’altro che mi sfugge riguardo al ripristino solo del database?

Sono nuovo a discourse, quindi cercherò di capire come aggirare il problema, ma questo sembra essere una priorità più alta se il backup/ripristino non funziona correttamente per gli utenti che hanno bucket S3 come archiviazione dei caricamenti.

Ecco i miei file di log del tentativo di ripristino.

[2025-06-22 16:02:24] /var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:81:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:385:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:352:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:69:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:49:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:167:in `restore_uploads'
/var/www/discourse/lib/backup_restore/restorer.rb:71:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:20:in `restore'
/var/www/discourse/script/spawn_backup_restore.rb:33:in `block in 
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `
[2025-06-22 16:02:24] Trying to rollback...

Aggiornamento sulla mia situazione specifica… Avevo ancora file nella mia directory /var/discourse/shared/standalone/uploads anche se ero passato a S3 per l’archiviazione. Una volta eliminata la directory ‘default’ in quella directory uploads, ho ricreato un backup e ne ha creato con successo uno solo del database (…sql.gz).

Per qualche motivo (nel mio caso) se ci sono file in quella directory, ignora l’impostazione per NON includere gli upload nel backup e li crea comunque.

Fatemi sapere se sono necessarie ulteriori informazioni o chiarimenti sulla mia situazione. Sembra che sia forse leggermente diverso dalla situazione dell’OP.

In ogni caso, sono riuscito a risolvere il problema e ora posso ripristinare con successo.