Ложные срабатывания по «посты не переназначены на новый URL загрузки S3»

Внести вклад Ошибка
1

Я мигрировал экземпляр Discourse с одного сервера на другой и столкнулся с интересной проблемой…

Мы используем S3 для хранения файлов, загружаемых на форум. Эта функция была включена несколько лет назад, поэтому она не была частью данной миграции.
После исправления нескольких других проблем мне удалось успешно импортировать резервную копию. Однако процесс завершился ошибкой на этапе, связанном с S3, с следующим сообщением:

Обновление URL-адресов в базе данных...
Удаление старых оптимизированных изображений...
Пометка всех постов, содержащих лайтбоксы, для пересборки...
72038 постов помечены для пересборки
ИСКЛЮЧЕНИЕ: 257 постов не сопоставлены с новым URL-адресом загрузки S3. Миграция S3 не удалась для БД 'default'.

После небольшого анализа я смог отследить проблему до этой строки:

Затем я зашел в консоль Rails и смог воспроизвести запросы следующим образом:

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

Далее я проверил эти конкретные посты: они оказались частью отчетов о производительности (скриншот сделан после выполнения скрипта поиска и замены):

На изображении показаны HTTP GET-запросы к различным конечным точкам веб-сайта образовательных технологий Keroiod.io (подпись сгенерирована ИИ)
На изображении показаны HTTP GET-запросы к различным конечным точкам веб-сайта образовательных технологий Keroiod.io (подпись сгенерирована ИИ)866×685 36.9 KB

Похоже, эта проверка извлекает любой пост, содержащий /uploads/default/original в поле cooked, даже если это не является легитимным ресурсом. В данном случае /uploads/default/original использовался как «обычный текст», поэтому он не был пропущен во время задачи миграции.

Не уверен, является ли это ожидаемым поведением?
Спасибо!

Migrate to s3 failed - but only check fails
2

Кажется, я видел похожие проблемы с обработанными постами.

Может, стоит попробовать восстановить только базу данных — тогда эти проверки будут пропущены.

Это то, что я бы попробовал следующим.

3

Мне удалось полностью восстановить это, просто заменив текст в этих сообщениях так, чтобы он не соответствовал фильтру. Для меня это не было проблемой, но я поднимаю этот вопрос на случай, если кто-то столкнётся с той же проблемой, — возможно, стоит исправить это в Discourse.

2 лайка
4

Да. Возможно, код просто не должен проверять готовые посты.

1 лайк
5

Я почти уверен, что столкнулся с этим же при попытке восстановить резервную копию, которую я создал с параметром «включить загрузки» в состоянии DISABLED. Не упускаю ли я что-то ещё при восстановлении только базы данных?

Я новичок в Discourse, поэтому постараюсь разобраться, как обойти эту проблему, но это кажется более приоритетным, если резервное копирование и восстановление не работают корректно для пользователей, использующих 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 <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'
[2025-06-22 16:02:24] Попытка отката...
6

Обновление по моей конкретной ситуации… У меня всё ещё были файлы в /var/discourse/shared/standalone/uploads, хотя я уже переключился на S3 для хранения. Как только я удалил директорию ‘default’ в этой папке uploads, я создал резервную копию, и она успешно создалась только с базой данных (…sql.gz).

По какой-то причине (в моём случае) если в этой директории есть файлы, система игнорирует настройку НЕ включать загрузки в резервную копию и создаёт их всё равно.

Дайте знать, если для моей ситуации нужна дополнительная информация или уточнения. Похоже, что она немного отличается от ситуации автора оригинального поста.

В любом случае мне удалось обойти проблему, и теперь я могу успешно восстанавливать данные.