with-cloudflare-d1 template is broken from v3.85.0

[kazuemon]

Describe the Bug

When I attempt to access the admin page, a module resolution error occurs and I am unable to open it.

Module not found: Can't resolve 'worker_threads'
  4 | const split = require('split2')
  5 | const { Duplex } = require('stream')
> 6 | const { parentPort, workerData } = require('worker_threads')
    |                                  ^
  7 |
  8 | function createDeferred () {
  9 |   let resolve

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./node_modules/.pnpm/pino-pretty@13.1.2/node_modules/pino-pretty/index.js
./node_modules/.pnpm/payload@3.85.0_graphql@16.14.0_typescript@5.7.3/node_modules/payload/dist/utilities/logger.js
./node_modules/.pnpm/payload@3.85.0_graphql@16.14.0_typescript@5.7.3/node_modules/payload/dist/index.js
./node_modules/.pnpm/payload@3.85.0_graphql@16.14.0_typescript@5.7.3/node_modules/payload/dist/utilities/getEntityPermissions/entityDocExists.js
./node_modules/.pnpm/payload@3.85.0_graphql@16.14.0_typescript@5.7.3/node_modules/payload/dist/utilities/getEntityPermissions/getEntityPermissions.js
./node_modules/.pnpm/payload@3.85.0_graphql@16.14.0_typescript@5.7.3/node_modules/payload/dist/exports/internal.js
./node_modules/.pnpm/@payloadcms+plugin-cloud-storage@3.85.0_@types+react@19.2.9_monaco-editor@0.55.1_next@15.4.11_j5wrcln45qasuerzxq2joth2fq/node_modules/@payloadcms/plugin-cloud-storage/dist/utilities/resolveSignedURLKey.js
./node_modules/.pnpm/@payloadcms+plugin-cloud-storage@3.85.0_@types+react@19.2.9_monaco-editor@0.55.1_next@15.4.11_j5wrcln45qasuerzxq2joth2fq/node_modules/@payloadcms/plugin-cloud-storage/dist/exports/utilities.js
./node_modules/.pnpm/@payloadcms+storage-r2@3.85.0_@types+react@19.2.9_monaco-editor@0.55.1_next@15.4.11_@babel+co_oztnqrx4zsk7tam7jwxz3aurv4/node_modules/@payloadcms/storage-r2/dist/client/R2ClientUploadHandler.js
 GET /admin 500 in 10882ms

Link to the code that reproduces this issue

https://github.com/kazuemon/payload-3.85.0-cf-d1-reproduction

Reproduction Steps

I have provided a link to the repository, but it is just the state immediately after running create-payload-app.

1. pnpx create-payload-app -t with-cloudflare-d1
2. pnpm dev
3. access http://localhost:3000/admin

Which area(s) are affected?

plugin: cloud-storage

Environment Info

Binaries:
  Node: 24.15.0
  npm: 10.9.2
  Yarn: 1.22.19
  pnpm: 9.15.9
Relevant Packages:
  payload: 3.85.0
  next: 15.4.11
  @payloadcms/db-d1-sqlite: 3.85.0
  @payloadcms/drizzle: 3.85.0
  @payloadcms/graphql: 3.85.0
  @payloadcms/next/utilities: 3.85.0
  @payloadcms/plugin-cloud-storage: 3.85.0
  @payloadcms/richtext-lexical: 3.85.0
  @payloadcms/storage-r2: 3.85.0
  @payloadcms/translations: 3.85.0
  @payloadcms/ui/shared: 3.85.0
  react: 19.2.1
  react-dom: 19.2.1
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025
  Available memory (MB): 31885
  Available CPU cores: 16

[jmtorres]

Confirming the same failure on @payloadcms/storage-vercel-blob@3.85.0 — pinning back to 3.84.1 resolves it. So this isn't R2-specific; any storage adapter whose ClientUploadHandler imports from @payloadcms/plugin-cloud-storage/exports/utilities will hit it.

Root cause

The regression comes from #16495 (and its 3.x backport #16510), which adds resolveSignedURLKey and re-exports it from packages/plugin-cloud-storage/src/exports/utilities.ts.

The *ClientUploadHandler files already import from that barrel, so even though they never call resolveSignedURLKey directly, importing the barrel pulls it in — which transitively drags into the client bundle:

• payload/exports/internal
  • → payload/utilities/logger → pino-pretty → worker_threads
  • → payload/uploads/safeFetch → undici → node:assert, node:async_hooks, node:buffer, …

Worth noting that #16495 only modified the R2 / S3 / Azure / GCS client handlers, not VercelBlobClientUploadHandler — so vercel-blob is regressing purely because of the barrel addition, not because its own code changed.

Suggested fix

The underlying dedup fix in #16495 is solving a real data-integrity bug and shouldn't be reverted. The issue is just that resolveSignedURLKey (server-only, needs DB access) is sharing a barrel with client-safe utilities like updateFilename.

Splitting exports/utilities into a client-safe barrel and a server-only barrel — or moving resolveSignedURLKey out of the shared one — would resolve this without losing the fix.

cc @AlessioGr — flagging since you have the full context from #16495 on why resolveSignedURLKey lives where it does.