From 8e32c7cee7c51cad509917ca90393f74188743fe Mon Sep 17 00:00:00 2001 From: Francisco Solla Date: Fri, 2 Oct 2026 19:35:24 -0300 Subject: [PATCH] =?UTF-8?q?fix(storage):=20desliga=20checksum=20autom?= =?UTF-8?q?=C3=A1tico=20de=20upload=20no=20client=20S3=20(Garage=20multipa?= =?UTF-8?q?rt)=20(C246-hotfix)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit O adapter storage-s3 usa multipart acima de 50 MB e o Garage grava um x-amz-checksum-crc32 errado; o SDK valida no GET e toda leitura do objeto falhava (500 nas fotos 80/83, panorâmicas de 54 MB — conteúdo correto). requestChecksumCalculation: WHEN_REQUIRED no client do plugin; a leitura segue validando o checksum que o objeto tiver e a varredura de integridade segue como checagem honesta. Os dois objetos foram reescritos com PUT único (checksum correto) no ops: canário 2/2 e URLs públicas 200 com 53.762.718 bytes. --- .../2026-10-02-c246-garage-checksum-multipart.md | 1 + docs/ops/teqo-1313-deploy.md | 11 +++++++++++ src/payload.config.ts | 9 +++++++++ 3 files changed, 21 insertions(+) create mode 100644 docs/changelog/2026-10-02-c246-garage-checksum-multipart.md diff --git a/docs/changelog/2026-10-02-c246-garage-checksum-multipart.md b/docs/changelog/2026-10-02-c246-garage-checksum-multipart.md new file mode 100644 index 00000000..38b70670 --- /dev/null +++ b/docs/changelog/2026-10-02-c246-garage-checksum-multipart.md @@ -0,0 +1 @@ +**C246-hotfix — checksum errado do Garage em uploads multipart >50 MB (2026-10-02):** a operação do C246 destravou um bug de storage que explicava as fotos 80/83: o adapter `@payloadcms/storage-s3` usa upload **multipart** acima de 50 MB e o Garage grava um `x-amz-checksum-crc32` que **não corresponde ao corpo** (medido: objeto de 53.762.718 bytes com checksum armazenado `j/yKJQ==` e conteúdo real `NE5FZQ==`); o SDK valida o checksum na resposta do GET e aborta, então toda leitura do objeto dava 500 — o conteúdo sempre esteve correto. As duas panorâmicas de 7952px (~54 MB) do acervo eram os únicos objetos nessa faixa. O reparo do C246 re-uploadava pelo mesmo caminho multipart e a verificação continuava falhando (o mesmo checksum errado era regravado). Correção estrutural: `requestChecksumCalculation: 'WHEN_REQUIRED'` no client do `s3Storage` (`src/payload.config.ts`) — o SDK para de anexar checksums de upload (o PUT único já gravava certo; o multipart era o defeito); as leituras seguem validando o checksum que o objeto tiver e a varredura de integridade (download + decode) continua sendo a checagem honesta. Ops imediato (sem deploy): reescrita dos dois objetos com PUT único dos bytes verificados do original do Flickr (sha256 `9108ed5c…`, idêntico nas duas fontes) — canário 2/2 íntegras e `/fotos/80/midia` + `/fotos/83/midia` respondendo 200 com os 53.762.718 bytes completos. Varredura completa anterior: 6.492 fotos, 6.490 íntegras, só as 2 corrompidas. Sem migration, sem UI. diff --git a/docs/ops/teqo-1313-deploy.md b/docs/ops/teqo-1313-deploy.md index 242abca1..7dffb8b7 100644 --- a/docs/ops/teqo-1313-deploy.md +++ b/docs/ops/teqo-1313-deploy.md @@ -1740,6 +1740,17 @@ O download do original no reparo tem teto de **15 min** — um original grande (~50 MB, ex. panorâmica 7952px) leva minutos no link lento da casa; falha de download é `failed` retentável, nunca rebaixamento. +**Originais >50 MB e o checksum do Garage (incidente 2026-10-02):** o adapter +`storage-s3` sobe arquivos grandes via multipart e o Garage gravava um +`x-amz-checksum-crc32` que não bate com o corpo — todo GET do objeto falhava na +validação do SDK (500 no proxy público), mesmo com o conteúdo correto. O client +do plugin ficou com `requestChecksumCalculation: 'WHEN_REQUIRED'` (não anexa +checksum de upload; a leitura segue validando o que o objeto tiver). Se um +objeto legado aparecer com esse sintoma (`checksum mismatch` no recibo e no +GET), a correção pontual é reescrever os mesmos bytes com **PUT único** pelo +client S3 (o PUT único grava o checksum certo) — ver changelog +`2026-10-02-c246-garage-checksum-multipart.md`. + Depois de um `--apply` que rebaixou alguma foto, buste a tag pública em um processo que a possui (o write do CLI não revalida o servidor Next): diff --git a/src/payload.config.ts b/src/payload.config.ts index 230a0762..bac28b03 100644 --- a/src/payload.config.ts +++ b/src/payload.config.ts @@ -223,6 +223,15 @@ export default buildConfig({ region: mediaStorage.region, endpoint: mediaStorage.endpoint, forcePathStyle: true, + // C246-ops (2026-10-02): Garage stores a WRONG + // `x-amz-checksum-crc32` for multipart uploads (the storage-s3 + // adapter switches to multipart above 50 MB), so every GET of a + // >50 MB object failed the SDK's response validation — the two + // archive originals affected were 54 MB panoramas. WHEN_REQUIRED + // stops the SDK from attaching upload checksums; reads still + // validate whatever checksum an object has and the integrity + // sweep is the honest corruption check (decode included). + requestChecksumCalculation: 'WHEN_REQUIRED', }, }), ]