Backups para Cloudflare R2 falham durante upload multipart com aws-sdk-s3 1.182.0 (método 'downcase' não definido para nil)

Contribuir Bug
1

Prioridade/Severidade:

Alta para instâncias auto-hospedadas que utilizam armazenamento de backup compatível com S3, pois os backups agendados falham após a criação do arquivo.

Plataforma:

Discourse auto-hospedado na branch mais recente.

Versão ao vivo atual quando observado: v2026.4.0-latest

Ruby: 3.4.0

aws-sdk-s3: 1.182.0

Descrição:

Os backups para o Cloudflare R2 falham na etapa final “Enviando arquivo…”.

O despejo do banco de dados e a criação do arquivo local são concluídos com sucesso, mas o upload multipart do arquivo de backup finalizado falha.

Resultado real:

O backup falha com:

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

O rastreamento de pilha inclui:

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

Resultado esperado:

O arquivo de backup deve ser enviado com sucesso para o armazenamento de backup compatível com S3 configurado.

Etapas reproduzíveis:

  1. Configure o armazenamento de backup para o Cloudflare R2 usando o caminho de backup compatível com S3.
  2. Utilize um arquivo de backup maior que o limite multipart.
  3. Execute um backup manual ou agendado.
  4. Observe a falha durante “Enviando arquivo…”.

Configuração relevante:

  • 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

Trecho do rastreamento de pilha observado:

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

Isso sugere que checksum_algorithm é nil no caminho de upload multipart.

Contexto adicional:

Existe um tópico recente semelhante no Meta para o Backblaze B2:

Além disso, as entradas do changelog do aws-sdk-s3 após a versão 1.182.0 parecem relevantes:

  • 1.201.0: Corrige o upload multipart para respeitar o modo request_checksum_calculation quando_required
  • 1.210.2: Recua para checksums de solicitação via cabeçalho ao usar endpoints personalizados ou provedores de endpoint para operações PutObject e UploadPart

O Discourse main atualmente ainda parece travar o aws-sdk-s3 na versão 1.182.0:

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

2

Não olho para isso há um tempo, mas assim que lidava com isso no passado:

Eles não consideram isso um Contribute > Bug porque não fingem dar suporte a cada serviço S3 não tão compatível no planeta.

Não me lembro exatamente para quais sites eu estava fazendo isso, mas não me lembro de ter alterado algo a respeito recentemente, então acho que essa ainda é a “melhor” solução alternativa.

Acho que houve alguns outros tópicos sobre isso quando a AWS lançou a nova biblioteca que quebrou as ofertas de todo mundo.

2 curtidas
3

Obrigado, isso resolveu o problema para mim.

Apliquei a solução alternativa diretamente no app.yml via after_bundle_exec, fixando o aws-sdk-s3 na versão 1.177.0 e o aws-sdk-core na 3.215, e então reconstruí o container. Depois disso, os backups manuais para o Cloudflare R2 voltaram a funcionar com sucesso, e os uploads pelo navegador que antes falharam também passaram a funcionar novamente.

No meu caso, as falhas apareciam como multipart upload failed: undefined method 'downcase' for nil no aws-sdk-s3 1.182.0.

Agradeço pela solução alternativa.

1 curtida
4

Correção… essa solução alternativa funcionou para mim também, eu só precisei colocá-la em seu próprio bloco hooks: e não adicioná-la a um bloco de hooks existente, que bobagem minha.

1 curtida