תוצאות חיוביות שגויות ב-"פוסטים לא ממופים מחדש לכתובת URL חדשה להעלאה ל-S3"

I was migrating our Discourse instance from a server to another, and came across an interesting issue…

We use S3 to store uploads from the forum. We have enabled them several years ago, hence it’s not something we introduced in this migration.
After fixing a couple of other issues, I was able to get the backup to be imported. But, it failed on a S3-related step with the following:

Updating the URLs in the database...
Removing old optimized images...
Flagging all posts containing lightboxes for rebake...
72038 posts were flagged for a rebake
EXCEPTION: 257 posts are not remapped to new S3 upload URL. S3 migration failed for db 'default'.

After digging a bit, I was able to trace down the issue to this line:

Then, I went to the rails console, and I was able to replicate the queries with the following:

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

Then, I went to those particular posts, and they were part of the Performance Reports (screenshot is from after I run a find-and-replace script):

Apparently, that check is retrieving any post containing /uploads/default/original in the cooked field, despite it might not be a legitimate asset. In this case, /uploads/default/original was used as “plain text”, hence it was not missed during the migration job.

Not sure if this is expected?
Thank you!

ראיתי בעיות דומות עם פוסטים “מבושלים”, אני חושב.

אולי אתה יכול לעשות שחזור של מסד נתונים בלבד ואז זה מדלג על הבדיקות האלה.

זה מה שהייתי מנסה הלאה.

הצלחתי לשחזר אותו במלואו פשוט על ידי החלפת הטקסט בפוסטים האלה כך שלא יתאים למסנן. זה לא היה בעיה עבורי, אבל רק מעלה את זה למקרה שמישהו יתמודד עם אותה בעיה, מכיוון שאולי כדאי לתקן את זה ב-Discourse.

2 לייקים

כן. אולי הקוד פשוט לא צריך לבדוק פוסטים מבושלים.

לייק 1

אני די בטוח שגם אני נתקלתי בזה כשניסיתי לשחזר גיבוי ויצרתי את הגיבוי כשהאפשרות “כלול העלאות” כבויה. האם יש משהו נוסף שאני מפספס בשחזור של מסד הנתונים בלבד?

אני חדש בדיסקרוס אז אנסה להבין איך לעקוף את זה, אבל זה נראה כמו עדיפות גבוהה יותר אם הגיבוי/שחזור לא עובד כראוי עבור משתמשים שיש להם דלי S3 כאחסון העלאות.

הנה קבצי הלוג שלי של ניסיון השחזור.

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

עדכון לגבי המצ
ב הספציפי שלי… עדיין היו לי קבצים ב-/var/discourse/shared/standalone/uploads למרות שהחלפתי ל-S3 לאחסון. לאחר שמחקתי את ספריית ‘default’ בספריית ההעלאות הזו ויצרתי מחדש גיבוי, הוא יצר בהצלחה גיבוי של מסד נתונים בלבד (…sql.gz).

מסיבה כלשהי (במקרה שלי), אם יש קבצים בספרייה זו, ההגדרה לא לכלול קבצים שהועלו בגיבוי מתעלמת ממנה והקבצים נוצרים בכל מקרה.

ספרו לי אם נדרש מידע נוסף או הבהרות למצבי. נראה שזה אולי שונה במקצת מהמצב של פותח השרשור.

בכל מקרה, הצלחתי לעקוף את הבעיה וכעת אני יכול לשחזר בהצלחה.