storage-vercel-blob: clientUploads makes the item unique after PUT so the new media link gets 404s and the existing file for non postfixed version is overwritten #17823

Activity

1. zakriabilal

   added

   status: needs-triagePossible bug which hasn't been reproduced yetPossible bug which hasn't been reproduced yet

   validate-reproductionAuto-added tag on create to tell bot to check recreation URL, removed after check.Auto-added tag on create to tell bot to check recreation URL, removed after check.

   v3

   on Aug 17, 2026
2. github-actions

   added

   plugin: otherOther plugins not listedOther plugins not listed

   and removed

   validate-reproductionAuto-added tag on create to tell bot to check recreation URL, removed after check.Auto-added tag on create to tell bot to check recreation URL, removed after check.

   on Aug 17, 2026
3. r1tsuu

   self-assigned this

   on Aug 17, 2026
4. github-actions

   removed

   status: needs-triagePossible bug which hasn't been reproduced yetPossible bug which hasn't been reproduced yet

   on Aug 17, 2026
5. LukasHechenberger commented on Sep 25, 2026

   

   LukasHechenberger

   on Sep 25, 2026

   More actions

   Confirming this reproduces identically on payload@3.90.2 / @payloadcms/storage-vercel-blob@3.90.2 with Vercel Blob on Postgres (not just Mongo) — same symptom (404 on the new doc's file, old doc's blob overwritten).

   Root cause, traced through getClientUploadRoute.js / authorizeFileOverwrite.js: authorizeClientOverwrite() matches the raw, pre-dedup requested filename against existing docs' filename. On a match it returns allowOverwrite: true unconditionally — there's no signal in the handshake distinguishing "creating a new doc" from "intentionally replacing this doc's file". So the client PUTs to the old, un-keyed prefix/filename path, while generateFileData() independently dedupes the new doc's filename field to photo-1.jpg — a path that was never written. Confirmed via direct DB inspection: every doc with a filename collision has _objectKey: null; every doc with a unique filename gets a correct UUID _objectKey from resolveSignedURLKey().

   We patched around it locally (pnpm patch) by forcing allowOverwrite to always be false in getClientUploadRoute.js, so every client upload goes through resolveSignedURLKey() and gets its own unique, _objectKey-keyed path. That's a blunt fix (it disables the "replace an existing doc's file via client upload" feature, which we don't use) — @zakriabilal's suggestion of uniquifying the blob key before the client PUT is the better general fix, since it'd preserve intentional-overwrite support. Happy to help test a PR against this.
6. franknoel commented on Sep 26, 2026

   

   franknoel

   on Sep 26, 2026

   More actions

   Adding to the 3.90.2 report above: the overwrite can also hit a different, existing image when an editor replaces the file on another document.

   On our staging site (storage-vercel-blob, clientUploads: true):

   • Image A had no _objectKey and was stored at staging/nature-pres-de-chez-vous.webp; it is used by published pages.
   • An editor replaced the file on image B with a file of the same name. authorizeClientOverwrite matched A, the only document at that prefix/filename, so the browser PUT replaced A's file.
   • On save, getSafeFileName renamed B to nature-pres-de-chez-vous-1.webp, a key the browser never uploaded to. Because it was a WebP, storage-vercel-blob: clientUploads stores WebP, GIF and cropped uploads as 0-byte objects #18333 then wrote a 0-byte object there.

   So one save overwrote an image already in use and left the edited one empty.

   The client-upload request only carries the collection, prefix, filename and MIME type, so the route cannot tell which document is being edited. The overwrite authorization also needs to know that document, and allow overwriting only its own key.

   #17824 targets the rename half, but it re-uploads file.data, which is empty for client uploads since #17856, so on Vercel Blob it would store 0 bytes (#18333).

   We switched to clientUploads: false until both are fixed.

   👍React with 👍1Reacted by VSME-TEE
7. milesroxas

   added a commit that references this issue on Oct 12, 2026

   refactor(media): Cloudflare R2 replaces Vercel Blob as the media origin

   ...

   6755fb7
8. w3jerry commented on Nov 7, 2026

   

   w3jerry

   on Nov 7, 2026

   More actions

   Still reproduces on 3.93.0, and I can add one more case that loses data: replacing a doc's file with a file of the same name, on that same doc. The save returns HTTP 200 and the editor sees no error.

   Doc before	Browser PUT goes to	Doc after	Result
   Has _objectKey, stored at <key>/file.pdf	file.pdf	<key>/file-1.pdf	Doc URL 404. Old object deleted. New bytes orphaned at file.pdf.
   No _objectKey, stored at file.pdf	file.pdf (overwrites it)	file-1.pdf	Doc URL 404. file.pdf is then deleted, so the old and the new file are both gone.

   A re-save can't recover either doc. The new-doc case from the original report also still fails on 3.93.0.

   Two details that may help with the fix:

   • getDocumentFileKeys in authorizeFileOverwrite.js builds keys from doc.prefix and ignores _objectKey. A keyed doc therefore "matches" prefix/filename, a path where its object isn't stored, so the upload is authorized to go there.
   • Nothing in payload/dist reads allowOverwrite. generateFileData still calls getSafeFileName, which matches the doc being replaced, so the rename happens even when overwriting the doc's own file. In the second row, the plugin's afterChange then sees different old and new keys and deletes the file that was just uploaded.

   The workaround from the first comment here (force allowOverwrite to false in getClientUploadRoute.js) fixed all three cases in the same tests on 3.90.2. On a real Vercel Blob store in production (3.90.2), a new doc with a filename already in use got a working file-1.pdf. Replacing a file with one whose name was already taken gave a working file-2.pdf and deleted the previous object. The target code in getClientUploadRoute.js is unchanged in 3.93.0, so the same patch should still apply.

   How I tested: the real admin UI in a browser against next build && next start, saving through the normal form. The adapter and plugin code ran for real, but the Vercel Blob API was a local stand-in, so the 3.93.0 results are not from a real store. Config: clientUploads: true, addRandomSuffix: true, disablePayloadAccessControl: true, on PDFs. I didn't test with addRandomSuffix: false, though these PDF uploads never received a suffix.

   payload, @payloadcms/storage-vercel-blob, @payloadcms/plugin-cloud-storage, @payloadcms/db-mongodb: 3.93.0
   next: 16.3.8
   node: 22.23.4
   mongodb: 7