Admin media upload probes signed upload URLs with R2 binding storage and returns `NOT_SUPPORTED`

[diogoascarneiro]

Description

When uploading media in the EmDash admin on a Cloudflare Workers site configured with the Cloudflare R2 binding storage adapter, the admin first calls the signed upload URL endpoint:

POST /_emdash/api/media/upload-url

That endpoint returns a failed JSON response because R2 binding storage does not support signed upload URLs:

{
  "success": false,
  "error": {
    "code": "NOT_SUPPORTED",
    "message": "Storage does not support signed upload URLs. Use direct upload."
  }
}

The admin then falls back to direct upload via:

POST /_emdash/api/media

In cases where the fallback succeeds, the upload still leaves an alarming failed request in DevTools and makes it look like media upload is broken. Since R2 binding storage is a known non-signed-upload adapter, I expected the admin either to skip the signed URL probe for that storage backend or to handle the fallback without surfacing a failed API call.

There also appears to be a possible side effect in the signed upload URL endpoint: it creates a pending media record before calling storage.getSignedUploadUrl(). For adapters that always throw NOT_SUPPORTED, each probe may create a temporary pending media row even though the upload is immediately retried through the direct upload path.

Steps to reproduce

1. Configure an EmDash site for Cloudflare Workers with R2 binding storage:

   import emdash from "emdash/astro";
   import { r2 } from "@emdash-cms/cloudflare";
   
   emdash({
     storage: r2({ binding: "MEDIA" }),
   });

2. Add the matching R2 binding in wrangler.jsonc:

   {
     "r2_buckets": [
       {
         "binding": "MEDIA",
         "bucket_name": "example-media"
       }
     ]
   }

3. Deploy/run the site on Cloudflare Workers.

4. Open /_emdash/admin and upload an image from the media library or an image field.

5. Observe the failed POST /_emdash/api/media/upload-url request returning NOT_SUPPORTED before the admin falls back to POST /_emdash/api/media.

Environment

• emdash version: 0.31.0
• @emdash-cms/admin version: 0.31.0
• @emdash-cms/cloudflare version: 0.31.0
• Node.js version: v22.22.3
• Runtime: Cloudflare Workers
• Storage: Cloudflare R2 binding adapter, r2({ binding: "MEDIA" })
• OS: macOS

Logs / error output

{
  "success": false,
  "error": {
    "code": "NOT_SUPPORTED",
    "message": "Storage does not support signed upload URLs. Use direct upload."
  }
}

[khoinguyenpham04]

Thanks @diogoascarneiro. I will look into this.

[Hridayesh13]

We hit this on the same setup (R2 binding + D1) and chased it for a while, so here is what we found on the side effect you flagged at the end — it is worse than a temporary row, and I have opened #2284 with a fix and a regression test.

The pending rows are permanent, not temporary. POST /_emdash/api/media/upload-url calls repo.createPending() at upload-url.ts:107, before emdash.storage.getSignedUploadUrl() at :117. R2 bindings throw NOT_SUPPORTED unconditionally — this is a property of the adapter, not a misconfiguration — so the route always reaches the catch and answers 501, but the insert has already committed and nothing rolls it back. Local storage behaves the same way.

They are also invisible. findMany() defaults to status='ready' and the list query exposes no status parameter, so they never surface in the Media Library or through GET /_emdash/api/media. cleanupPendingUploads() exists, but I could not find anything scheduling it. So the media table grows by one dead row per upload attempt, indefinitely, on every deployment using an adapter that cannot pre-sign.

Measured on our install:

SELECT COUNT(*) FROM media WHERE status='pending';  -> 10
POST /_emdash/api/media/upload-url                  -> 501 NOT_SUPPORTED
SELECT COUNT(*) FROM media WHERE status='pending';  -> 11

11 had accumulated across one short debugging session, and we only noticed while instrumenting something unrelated.

#2284 moves the getSignedUploadUrl() call above createPending(), so the row is written only once it is known a URL can be issued. The 501 and the client fallback are unchanged; the test pins that contract so the fix cannot quietly alter it.

That deliberately does not address the half you actually opened this for — whether the admin should skip the signed-URL probe entirely for adapters known not to support pre-signing, rather than making a request that shows up failed in DevTools. That needs something like a capability flag on the Storage interface, which is a design call for the maintainers, so I left this issue to carry it.

_{Investigated with AI assistance (Claude Opus 5). The reporter is responsible for correctness.}