# Backups to Cloudflare R2 fail during multipart upload with aws-sdk-s3 1.182.0 (undefined method 'downcase' for nil)
**URL:** https://meta.discourse.org/t/backups-to-cloudflare-r2-fail-during-multipart-upload-with-aws-sdk-s3-1-182-0-undefined-method-downcase-for-nil/399768
**Category:** Bug
**Created:** [2 april 2026 om 05:07 UTC](https://meta.discourse.org/t/backups-to-cloudflare-r2-fail-during-multipart-upload-with-aws-sdk-s3-1-182-0-undefined-method-downcase-for-nil/399768 "2026-04-02T05:07:05Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@hel\_Sinki](https://meta.discourse.org/u/hel_Sinki)
#### Post date: [2 april 2026 om 05:07 UTC](https://meta.discourse.org/t/backups-to-cloudflare-r2-fail-during-multipart-upload-with-aws-sdk-s3-1-182-0-undefined-method-downcase-for-nil/399768/1 "2026-04-02T05:07:05Z")
**Priority/Severity:**
High for self-hosted instances using S3-compatible backup storage, because scheduled backups fail after archive creation.
**Platform:**
Self-hosted Discourse on latest branch.
Current live version when observed: v2026.4.0-latest
Ruby: 3.4.0
aws-sdk-s3: 1.182.0
**Description:**
Backups to Cloudflare R2 fail at the final “Uploading archive…” step.
The database dump and local archive creation complete successfully, but multipart upload of the finished backup archive fails.
**Actual result:**
The backup fails with:
```plaintext
EXCEPTION: multipart upload failed: undefined method 'downcase' for nil
```
**Stack trace includes:**
```plaintext
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
```
**Expected result:**
The backup archive should upload successfully to the configured S3-compatible backup store.
**Reproducible steps:**
1. Configure backup storage to Cloudflare R2 using the S3-compatible backup path.
2. Use a backup archive larger than the multipart threshold.
3. Run a manual or scheduled backup.
4. Observe failure during “Uploading archive…”.
**Relevant configuration:**
- 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
**Observed stack trace excerpt:**
```plaintext
algorithm = resp.context.params[:checksum_algorithm]
k = "checksum_#{algorithm.downcase}".to_sym
```
This suggests checksum\_algorithm is nil in the multipart upload path.
Additional context:
There is a similar recent Meta topic for Backblaze B2:
> [@Error uploading backup to B2](https://meta.discourse.org/t/error-uploading-backup-to-b2/393682):
>
> 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…
Also, aws-sdk-s3 changelog entries after 1.182.0 appear relevant:
- 1.201.0: Fix multipart upload to respect request\_checksum\_calculation when\_required mode
- 1.210.2: Falls back to header request checksums when using custom endpoints or endpoint providers for PutObject and UploadPart operations
Discourse main currently still appears to lock aws-sdk-s3 to 1.182.0:
[https://raw.githubusercontent.com/discourse/discourse/main/Gemfile.lock](https://raw.githubusercontent.com/discourse/discourse/main/Gemfile.lock)
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2 april 2026 om 14:49 UTC](https://meta.discourse.org/t/backups-to-cloudflare-r2-fail-during-multipart-upload-with-aws-sdk-s3-1-182-0-undefined-method-downcase-for-nil/399768/2 "2026-04-02T14:49:26Z")
I haven’t looked at this in a while, but here’s how I’ve dealt with this in the past:
> [@Can't rebuild due to AWS SDK gem bump and new AWS Data Integrity Protections](https://meta.discourse.org/t/cant-rebuild-due-to-aws-sdk-gem-bump-and-new-aws-data-integrity-protections/354217/49):
>
> 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 …
They don’t consider it a #Contribute > Bug because they don’t pretend to support every S3-not-so-compatible service on the planet.
I can’t remember just which sites I was doing this for, but I don’t remember changing anything about this recently, so I’m thinking that this is still the “best” workaround.
I think there were some other topics about this when AWS released the new library that broke everyone else’s offerings.
---
### Author:  [@hel\_Sinki](https://meta.discourse.org/u/hel_Sinki)
#### Post date: [2 april 2026 om 15:32 UTC](https://meta.discourse.org/t/backups-to-cloudflare-r2-fail-during-multipart-upload-with-aws-sdk-s3-1-182-0-undefined-method-downcase-for-nil/399768/3 "2026-04-02T15:32:49Z")
Thanks, this fixed it for me.
I applied the workaround directly in `app.yml` via `after_bundle_exec`, pinned `aws-sdk-s3` to `1.177.0` and `aws-sdk-core` to `3.215`, then rebuilt the container. After that, manual backups to Cloudflare R2 succeeded again, and the previously failing browser uploads started working again as well.
In my case the failures were showing up as `multipart upload failed: undefined method 'downcase' for nil` on `aws-sdk-s3 1.182.0`.
Appreciate the workaround.
---
### Author:  [@amiantos](https://meta.discourse.org/u/amiantos)
#### Post date: [4 april 2026 om 07:30 UTC](https://meta.discourse.org/t/backups-to-cloudflare-r2-fail-during-multipart-upload-with-aws-sdk-s3-1-182-0-undefined-method-downcase-for-nil/399768/4 "2026-04-04T07:30:33Z")
Correction… this workaround worked for me too, I just had to put it in its own `hooks:` block and not add it to an existing hooks block, silly me.