Backups nach Cloudflare R2 schlagen während des Multipart-Uploads mit aws-sdk-s3 1.182.0 fehl (undefined method 'downcase' for nil)

[hel_Sinki]

Priorität/Schweregrad:

Hoch für selbst gehostete Instanzen, die S3-kompatiblen Backup-Speicher verwenden, da geplante Backups nach der Archivierung fehlschlagen.

Plattform:

Selbst gehostetes Discourse auf dem neuesten Branch.

Aktuelle Live-Version bei Beobachtung: v2026.4.0-latest

Ruby: 3.4.0

aws-sdk-s3: 1.182.0

Beschreibung:

Backups zu Cloudflare R2 scheitern am letzten Schritt „Archiv wird hochgeladen…".

Der Datenbank-Dump und die lokale Archivierung werden erfolgreich abgeschlossen, aber der multipart-Upload des fertigen Backup-Archivs schlägt fehl.

Tatsächliches Ergebnis:

Das Backup schlägt fehl mit:

EXCEPTION: multipart upload failed: undefined method 'downcase' for nil

Der Stack-Trace enthält:

aws-sdk-s3-1.182.0/lib/aws-sdk-s3/multipart_file_uploader.rb
lib/backup_restore/s3_backup_store.rb:48
lib/backup_restore/creator.rb:434

Erwartetes Ergebnis:

Das Backup-Archiv sollte erfolgreich in den konfigurierten S3-kompatiblen Backup-Speicher hochgeladen werden.

Reproduzierbare Schritte:

1. Backup-Speicher auf Cloudflare R2 unter Verwendung des S3-kompatiblen Backup-Pfads konfigurieren.
2. Ein Backup-Archiv verwenden, das größer als der Multipart-Schwellenwert ist.
3. Ein manuelles oder geplantes Backup ausführen.
4. Fehler während „Archiv wird hochgeladen…" beobachten.

Relevante Konfiguration:

• DISCOURSE_BACKUP_LOCATION=s3
• DISCOURSE_S3_ENDPOINT=https://.r2.cloudflarestorage.com
• DISCOURSE_S3_FORCE_PATH_STYLE=true
• DISCOURSE_S3_BACKUP_BUCKET=
• AWS_REQUEST_CHECKSUM_CALCULATION=WHEN_REQUIRED
• AWS_RESPONSE_CHECKSUM_VALIDATION=WHEN_REQUIRED

Beobachteter Stack-Trace-Auszug:

algorithm = resp.context.params[:checksum_algorithm]
k = "checksum_#{algorithm.downcase}".to_sym

Dies deutet darauf hin, dass checksum_algorithm im Multipart-Upload-Pfad nil ist.

Zusätzlicher Kontext:

Es gibt ein ähnliches, kürzlich erschienenes Meta-Thema zu Backblaze B2:

Error uploading backup to B2

I’m facing issues with backing up my Discourse instance, the instance is setup to upload to Backblaze’s B2. Error log: Making sure archive does not already exist... Creating empty archive... Archiving data dump... Archiving uploads... Skipping uploads stored on S3. Removing tmp '/var/www/discourse/tmp/backups/default/2026-01-16-151337' directory... Gzipping archive, this may take a while... Uploading archive... EXCEPTION: failed to abort multipart upload: SSL_read: unexpected eof while reading…

Außerdem scheinen Einträge im aws-sdk-s3-Änderungsprotokoll nach Version 1.182.0 relevant zu sein:

• 1.201.0: Behebung, damit Multipart-Uploads den request_checksum_calculation-Modus WHEN_REQUIRED einhalten
• 1.210.2: Fällt auf Header-Request-Prüfsummen zurück, wenn benutzerdefinierte Endpunkte oder Endpunkt-Provider für PutObject- und UploadPart-Operationen verwendet werden

Discourse main scheint aws-sdk-s3 derzeit weiterhin auf Version 1.182.0 zu fixieren:

https://raw.githubusercontent.com/discourse/discourse/main/Gemfile.lock

[pfaffman (Jay Pfaffman)]

Ich habe mir das eine Weile nicht angesehen, aber so habe ich das in der Vergangenheit gelöst:

Can't rebuild due to AWS SDK gem bump and new AWS Data Integrity Protections

But I did for a site that’s using Backblaze. I created a template I put in /root/aws-revert-template.yml with this: # This template reverts aws-sdk-s3 to a version that works with backblaze params: home: /var/www/discourse hooks: after_bundle_exec: - exec: cd: $home cmd: - 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 …

Sie betrachten es nicht als bug, da sie nicht behaupten, jeden S3-nicht-so-kompatiblen Dienst auf dem Planeten zu unterstützen.

Ich kann mich nicht mehr genau daran erinnern, für welche Seiten ich das gemacht habe, aber ich habe mich nicht daran erinnert, dass ich daran kürzlich etwas geändert habe. Daher denke ich, dass dies immer noch die „beste" Workaround-Lösung ist.

Ich glaube, es gab damals noch andere Themen dazu, als AWS die neue Bibliothek veröffentlichte, die die Angebote aller anderen kaputt gemacht hat.

[hel_Sinki]

Danke, das hat bei mir funktioniert.

Ich habe den Workaround direkt in app.yml über after_bundle_exec angewendet, aws-sdk-s3 auf 1.177.0 und aws-sdk-core auf 3.215 festgelegt und dann den Container neu erstellt. Danach funktionierten manuelle Backups nach Cloudflare R2 wieder, und auch die zuvor fehlgeschlagenen Browser-Uploads liefen wieder.

In meinem Fall traten die Fehler mit der Meldung multipart upload failed: undefined method 'downcase' for nil bei aws-sdk-s3 1.182.0 auf.

Ich schätze den Workaround sehr.

[amiantos (Brad Root)]

Korrektur… diese Lösung hat bei mir auch funktioniert. Ich musste sie einfach in einen eigenen hooks:-Block setzen und nicht zu einem bestehenden hooks-Block hinzufügen, wie dumm von mir.