Faux positifs sur "les messages ne sont pas remappés vers une nouvelle URL de téléchargement S3"

Bug
1

J’étais en train de migrer notre instance Discourse d’un serveur à un autre, et je suis tombé sur un problème intéressant…

Nous utilisons S3 pour stocker les téléchargements du forum. Nous les avons activés il y a plusieurs années, ce n’est donc pas quelque chose que nous avons introduit dans cette migration.
Après avoir résolu quelques autres problèmes, j’ai pu importer la sauvegarde. Mais cela a échoué à une étape liée à S3 avec le message suivant :

Mise à jour des URL dans la base de données...
Suppression des anciennes images optimisées...
Marquage de tous les posts contenant des lightboxes pour un nouveau rendu...
72038 posts ont été marqués pour un nouveau rendu
EXCEPTION : 257 posts ne sont pas remappés vers la nouvelle URL de téléchargement S3. La migration S3 a échoué pour la base de données 'default'.

Après avoir creusé un peu, j’ai pu remonter le problème jusqu’à cette ligne :

Ensuite, je suis allé dans la console Rails et j’ai pu reproduire les requêtes avec ce qui suit :

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}%'")
=> ...

Ensuite, je suis allé voir ces posts particuliers, et ils faisaient partie des rapports de performance (la capture d’écran est après que j’aie exécuté un script de recherche et remplacement) :

L'image montre des requêtes HTTP GET ciblant divers points de terminaison sur un site Web de communauté technologique éducative Keroiod.io. (Légendé par l'IA)
L'image montre des requêtes HTTP GET ciblant divers points de terminaison sur un site Web de communauté technologique éducative Keroiod.io. (Légendé par l'IA)866×685 36.9 KB

Apparemment, cette vérification récupère tout post contenant /uploads/default/original dans le champ cooked, même si ce n’est pas un actif légitime. Dans ce cas, /uploads/default/original a été utilisé comme “texte brut”, il n’a donc pas été manqué pendant le travail de migration.

Je ne sais pas si c’est attendu ?
Merci !

2

J’ai vu des problèmes similaires avec des publications corrompues, je crois.

Peut-être pouvez-vous faire une restauration de la base de données uniquement et ensuite il saute ces vérifications.

C’est ce que j’essaierais ensuite.

3

J’ai pu le restaurer complètement en remplaçant simplement le texte de ces publications pour qu’il ne corresponde pas au filtre. Ce n’était pas un problème pour moi, mais je le signale au cas où quelqu’un d’autre rencontrerait le même problème, car cela vaut peut-être la peine de le corriger dans Discourse.

2 « J'aime »
4

Ouais. Peut-être que le code ne devrait tout simplement pas vérifier les publications “cooked”.

1 « J'aime »
5

Je suis à peu près sûr que j’ai rencontré cela aussi en tentant de restaurer une sauvegarde et que j’ai créé la sauvegarde avec “inclure les téléchargements” désactivé. Y a-t-il autre chose que je manque avec la restauration de la base de données uniquement ?

Je suis nouveau sur Discourse, donc j’essaierai de trouver une solution de contournement, mais cela semble être une priorité plus élevée si la sauvegarde/restauration ne fonctionne pas correctement pour les utilisateurs qui ont des buckets S3 comme stockage de téléchargements.

Voici mes fichiers journaux de la restauration tentée.

[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...
6

Mise à jour sur ma situation spécifique… J’avais encore des fichiers dans mon /var/discourse/shared/standalone/uploads même si j’étais passé au S3 pour le stockage. Une fois que j’ai supprimé le répertoire ‘default’ dans ce répertoire d’uploads, j’ai recréé une sauvegarde et j’en ai créé une avec succès qui ne contenait que la base de données (…sql.gz).

Pour une raison quelconque (dans mon cas), s’il y a des fichiers dans ce répertoire, il ignore le paramètre pour NE PAS inclure les uploads dans la sauvegarde et les crée quand même.

Faites-moi savoir si plus d’informations ou de clarifications sont nécessaires pour ma situation. Il semble que ce soit peut-être légèrement différent de la situation de l’OP.

Quoi qu’il en soit, j’ai pu contourner le problème et je peux maintenant restaurer avec succès.