Backup upload failure due to uninitialized TransferManager

Ondersteuning Installatie
1

After updating to v2026.8.0-latest.1 +4, my backups have started failing. These are the logs: log.txt.zip (22.1 KB)

In particular, here’s the section that looks relevant:

[2026-08-04 03:37:52] Uploading archive...
[2026-08-04 03:37:52] EXCEPTION: uninitialized constant Aws::S3::TransferManager
[2026-08-04 03:37:52] /var/www/discourse/lib/s3_helper.rb:453:in 'S3Helper#transfer_manager'
/var/www/discourse/lib/s3_helper.rb:332:in 'S3Helper#upload_file'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:48:in 'BackupRestore::S3BackupStore#upload_file'
/var/www/discourse/lib/backup_restore/creator.rb:437:in 'BackupRestore::Creator#upload_archive'
/var/www/discourse/lib/backup_restore/creator.rb:41:in 'BackupRestore::Creator#run'
/var/www/discourse/lib/backup_restore.rb:13:in 'BackupRestore.backup!'
/var/www/discourse/app/jobs/regular/create_backup.rb:10:in 'Jobs::CreateBackup#execute'
/var/www/discourse/app/jobs/base.rb:313:in 'block (2 levels) in Jobs::Base#perform'

I’m not sure how to solve this issue.

2

I updated to v2026.9.0-latest +565, but I still ran into the same exact issue.

3

The Discourse version you’re running includes an aws-sdk-s3 version that should provide Aws::S3::TransferManager.

Are you using the official Discourse Docker installation? If you’re using the official Docker setup, was the container fully rebuilt as part of the upgrade?

4

Yes, I believe I’m using the official Discourse Docker installation. Is there a way for me to know for sure? It’s been a while since I’ve performed the installation.

To update, I ran ./launcher rebuild app. I assume this means the container was fully rebuilt, but maybe I’m mistaken?

A few more details that may be relevant:

  • Running Ubuntu 24.04.4 LTS
  • app.yml installs the official docker_manager and discourse-doc-categories plugins in the after_code hook. There are no other plugins defined in app.yml.
  • I’m trying to store the backups in an S3-compatible storage provided by Backblaze, and this had worked beforehand.
5

One thing that may help narrow this down is checking which aws-sdk-s3 gem is actually being loaded inside the running container.

The Discourse change which introduced Aws::S3::TransferManager also
bumped aws-sdk-s3 from 1.182.0 to 1.227.0:

At the Discourse revision you linked, Gemfile.lock should still be using
aws-sdk-s3 1.227.0, which does provide Aws::S3::TransferManager.

Could you try entering the container:

cd /var/discourse

./launcher enter app

Then, inside the container:

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
'

It may also be useful to check the application itself under Rails:

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
'

Then leave the container with:

logout

If that reports an older aws-sdk-s3, or TransferManager is missing,
that would explain the backup exception and would suggest that the container’s installed gems don’t match the current Discourse
Gemfile.lock.

If it reports 1.227.0 and successfully resolves
Aws::S3::TransferManager, then the issue is more unusual and we’d know to look at what differs between the Sidekiq backup process and that interactive environment.

Since you’re using ./launcher rebuild app, that does sound like the standard discourse_docker workflow; the commands above should tell us more precisely what actually ended up in the rebuilt container.