「posts are not remapped to new S3 upload URL」の誤検出

バグ
1

サーバーから別のサーバーへ Discourse インスタンスを移行していたところ、興味深い問題に遭遇しました。

フォーラムからのアップロードは S3 に保存しています。これは数年前に有効にしたもので、今回の移行で導入したものではありません。
他のいくつかの問題を修正した後、バックアップをインポートできるようになりました。しかし、S3 関連のステップで以下のエラーが発生しました。

データベース内の URL を更新中...
古い最適化された画像を削除中...
ライトボックスを含むすべての投稿を再ベイク対象にフラグ付け中...
72038 件の投稿が再ベイク対象にフラグ付けされました
例外: 257 件の投稿が新しい S3 アップロード URL にリマップされていません。db 'default' の S3 移行に失敗しました。

しばらく調査した結果、問題はこの行に起因することがわかりました。

その後、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}%'")
=> ...

その後、これらの特定の投稿を確認したところ、それらはパフォーマンスレポートの一部でした（スクリーンショットは、検索および置換スクリプトを実行した後のものです）。

The image shows HTTP GET requests targeting various endpoints on a Keroiod.io educational technology community website. (Captioned by AI)
The image shows HTTP GET requests targeting various endpoints on a Keroiod.io educational technology community website. (Captioned by AI)866×685 36.9 KB

どうやら、このチェックは、正当なアセットではない可能性があるにもかかわらず、cooked フィールドに /uploads/default/original を含む投稿を取得しているようです。この場合、/uploads/default/original は「プレーンテキスト」として使用されていたため、移行ジョブ中に見逃されることはありませんでした。

これは予期された動作でしょうか？
ありがとうございます！

2

調理済みの投稿で同様の問題を見たことがあると思います。

データベースのみを復元して、それらのチェックをスキップできるかもしれません。

次にそれを試してみます。

3

それらの投稿のテキストをフィルターに一致しないように置き換えるだけで、完全に復元できました。私にとっては問題ありませんでしたが、誰かが同じ問題に直面した場合に備えて、Discourseで修正する価値があるかもしれません。

「いいね！」 2
4

ええ。たぶん、コードは調理済みの投稿をチェックすべきではないでしょう。

「いいね！」 1
5

バックアップを復元しようとした際に私もこれに遭遇したと思います。その際、「アップロードを含める」を無効にしてバックアップを作成しました。データベースのみの復元で何か見落としていることはありますか？

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 
/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

私の具体的な状況についてのアップデートですが…ストレージをS3に切り替えたにもかかわらず、/var/discourse/shared/standalone/uploads にファイルが残っていました。そのアップロードディレクトリ内の default ディレクトリを削除し、バックアップを再作成したところ、データベースのみ（…sql.gz）のものが正常に作成されました。

何らかの理由で（私の場合は）、そのディレクトリにファイルが存在すると、バックアップにアップロードを含めないという設定を無視して、それらを anyway 作成してしまうようです。

私の状況について、さらに情報や明確化が必要な場合はお知らせください。これはOP（元の投稿者）の状況とは少し異なるようです。

いずれにしても、この問題は回避でき、現在は正常に復元できます。