初期化されていないTransferManagerによるバックアップアップロードの失敗

サポート インストール
7

この件について1つ思うことがあります：このような一時的な互換性テンプレートは、Discourseの依存関係を無期限に上書きし続けるよりも、自己期限切れやガード条件のようなものを持つ方が安全かもしれません。

例えば、一時的なソースバックポートについては、本番環境でフックを使用する予定です。まずアップストリームの修正がすでに存在するかどうかをチェックし、まだ必要であればパッチを適用します。

この場合、次のような処理を行っていれば、Discourse自体が新しいSDKの機能に依存し始めた時点で、古い aws-sdk-s3 1.177.0 のピン留めが続くのを防ぐことができた可能性があります：

hooks:
  after_bundle_exec:
    - exec:
        cd: $home
        cmd:
          - |
            if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
              echo "Discourse now requires Aws::S3::TransferManager; skipping obsolete Backblaze aws-sdk-s3 downgrade"
            else
              echo "Applying temporary Backblaze aws-sdk-s3 compatibility pin"
              bundle config set frozen false
              sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
              bundle update aws-sdk-s3
              bundle add aws-sdk-core --version 3.215
            fi

この特定のチェックはあくまで例示です。より一般的なバージョンチェック、またはDiscourseが想定されるSDKバージョンを超えた際に明示的に失敗させる方が、おそらくより良い解決策となるでしょう。

Discourseが期待するバージョンとgemが一致しなくなったコンテナを黙って生成するよりも、大きなエラー（loudly failing）で失敗させる方が望ましいと考えられます。