Die von dir genutzte Discourse-Version enthält eine aws-sdk-s3-Version, die Aws::S3::TransferManager bereitstellen sollte.
Nutzt du die offizielle Discourse-Docker-Installation? Falls du das offizielle Docker-Setup verwendest, wurde der Container im Rahmen des Upgrades vollständig neu aufgebaut?
Ja, ich glaube, ich nutze die offizielle Discourse-Docker-Installation. Gibt es eine Möglichkeit, das sicher zu überprüfen? Es ist schon eine Weile her, dass ich die Installation durchgeführt habe.
Um zu aktualisieren, habe ich ./launcher rebuild app ausgeführt. Ich nehme an, das bedeutet, dass der Container vollständig neu erstellt wurde, aber vielleicht liege ich da falsch?
Noch ein paar Details, die relevant sein könnten:
Läuft Ubuntu 24.04.4 LTS
app.yml installiert die offiziellen Plugins docker_manager und discourse-doc-categories im after_code-Hook. In app.yml sind keine weiteren Plugins definiert.
Ich versuche, die Backups in einem S3-kompatiblen Speicher von Backblaze abzulegen, was vorher funktioniert hat.
Ein möglicher Ansatz, um das Problem einzugrenzen, besteht darin zu prüfen, welche aws-sdk-s3-Gem tatsächlich im laufenden Container geladen wird.
Die Änderung in Discourse, die Aws::S3::TransferManager eingeführt hat, hat die Version von aws-sdk-s3 von 1.182.0 auf 1.227.0 erhöht:
Bei der von Ihnen verlinkten Discourse-Revision sollte Gemfile.lock weiterhin aws-sdk-s3 1.227.0 verwenden, das Aws::S3::TransferManager bereitstellt.
Könnten Sie versuchen, in den Container einzusteigen:
cd /var/discourse
./launcher enter app
Anschließend im Inneren des Containers:
cd /var/www/discourse
bundle info aws-sdk-s3
bundle exec ruby -e '
require "aws-sdk-s3"
puts "gem: #{Gem.loaded_specs["aws-sdk-s3"]&.full_name}"
puts "path: #{Gem.loaded_specs["aws-sdk-s3"]&.full_gem_path}"
p Aws::S3.autoload?(:TransferManager)
p Aws::S3::TransferManager
'
Es kann auch hilfreich sein, die Anwendung selbst unter Rails zu überprüfen:
RAILS_ENV=production bundle exec rails runner '
puts "aws-sdk-s3: #{Gem.loaded_specs["aws-sdk-s3"]&.version}"
p Aws::S3.autoload?(:TransferManager)
p Aws::S3::TransferManager
'
Verlassen Sie den Container anschließend mit:
logout
Falls dabei eine ältere Version von aws-sdk-s3 gemeldet wird oder TransferManager fehlt, würde dies die Backup-Ausnahme erklären und darauf hindeuten, dass die im Container installierten Gems nicht mit der aktuellen Discourse-Gemfile.lock übereinstimmen.
Falls 1.227.0 gemeldet wird und Aws::S3::TransferManager erfolgreich aufgelöst wird, ist das Problem ungewöhnlicher, und wir müssten untersuchen, was zwischen dem Sidekiq-Backup-Prozess und dieser interaktiven Umgebung unterschiedlich ist.
Da Sie ./launcher rebuild app verwenden, klingt das nach dem Standard-Workflow für discourse_docker; die obigen Befehle sollten uns genauer aufzeigen, was tatsächlich im neu aufgebauten Container gelandet ist.
Beim Nachforschen ist mir eingefallen, dass ich diesen Workaround verwendet habe, um ein Problem zu umgehen, bei dem das AWS SDK mit Backblaze nicht funktionierte. Beim Lesen des Themas sehe ich, dass Backblaze ihre API aktualisiert hat, wodurch der Workaround überflüssig wird.
Nachdem ich den Workaround entfernt hatte, war das Backup erfolgreich! Danke für die Hilfe.
Ein Gedanke dazu: Temporäre Kompatibilitätstemplates wie dieses wären möglicherweise sicherer, wenn sie eine Art von selbstlöschender oder schützender Bedingung aufweisen, anstatt die Abhängigkeiten von Discourse dauerhaft zu überschreiben.
Zum Beispiel plane ich bei temporären Quellcode-Backports, in der Produktion Hooks zu verwenden, die zunächst prüfen, ob der Upstream-Fix bereits vorhanden ist, und das Patch nur dann anwenden, wenn es noch benötigt wird.
In diesem Fall hätte etwas in dieser Form möglicherweise verhindert, dass das alte aws-sdk-s3 1.177.0-Pinning fortbesteht, sobald Discourse selbst von neueren SDK-Funktionen abhängt:
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- |
if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
echo "Discourse benötigt jetzt Aws::S3::TransferManager; überholtes Backblaze aws-sdk-s3-Downgrade wird übersprungen"
else
echo "Temporäre Backblaze aws-sdk-s3-Kompatibilitäts-Pinning wird angewendet"
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
Dieser spezifische Check ist nur beispielhaft – eine allgemeinere Versionsprüfung oder ein expliziter Fehlerfall, wenn Discourse die erwartete SDK-Version überschreitet, wäre wahrscheinlich besser.
Selbst ein lautes Scheitern wäre wahrscheinlich vorzuziehen, als stillschweigend einen Container zu erzeugen, dessen Gems nicht mehr mit den von Discourse erwarteten Versionen übereinstimmen.
Ich stimme zwar zu, dass es schön gewesen wäre, wenn die Software deutlich auf den Fehler hingewiesen hätte, aber der eigentliche Grund war, dass ich die Gems bewusst nicht auf die von Discourse erwarteten Versionen abstimmen wollte. Die neuere Version von aws-sdk-s3 sendete Header, die Backblaze nicht unterstützte, und ich wollte, dass die Backups trotzdem funktionieren.
Ich weiß nicht, ob es eine Prüfung gab, die ich proaktiv hätte einrichten können, um mich zu benachrichtigen, sobald der Workaround nicht mehr nötig war. Ich hatte den Workaround vor anderthalb Jahren im April 2025 implementiert, noch bevor eine Korrektur verfügbar war.
Ich denke, das Beste, was ich hätte tun können, wäre gewesen, ein Ablaufdatum festzulegen, um mich zu zwingen zu prüfen, ob der Workaround noch erforderlich ist. Eine solche Funktion wäre vielleicht hilfreich. Oder vielleicht liegt es an mir, proaktiver zu sein und mir Erinnerungen zu setzen, um zu überprüfen, ob der Workaround noch nötig ist. Dass ich einige Notizen angelegt hatte, hat mir in dieser Hinsicht geholfen.
