D1 remote binding returns empty body under `vite dev`

Describe the bug

When a SvelteKit app built with @sveltejs/adapter-cloudflare uses a D1 binding with "remote": true in wrangler.jsonc, querying it from a +page.server.ts load function under vite dev fails with:

D1_ERROR: Failed to parse body as JSON, got:

The body D1's client is trying to parse is empty (zero-length). This happens on every request, not intermittently, and does not resolve itself once the dev server has fully started (ruling out a startup race with the remote binding tunnel).

Running the identical query directly against the same database via the wrangler CLI, from the same machine/account, at the same time, succeeds every time:

wrangler d1 execute <db-name> --remote --command "SELECT * FROM items"

This isolates the failure to the dev-time platform emulation path used by vite dev + @sveltejs/adapter-cloudflare (which calls wrangler's getPlatformProxy remote-bindings/mixed-mode machinery internally) - not the D1 API, not account/auth, not network, and not a wrangler CLI regression. We tested wrangler 4.113.0 through 4.118.0; the CLI query succeeds on all of them, only the SvelteKit dev load path fails.

Switching the same binding to local D1 (removing remote: true, applying the schema with --local instead) works correctly - this is a viable workaround but means dev doesn't see real remote data.

In production (deployed worker), the same D1 queries work fine - this only reproduces under vite dev.

Reproduction

https://github.com/The-LukeZ/sveltekit-d1-remote-empty-body

Logs

Error: D1_ERROR: Failed to parse body as JSON, got:
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    at async NotesRepository.listMeetings (src/lib/server/db.ts:23:19)
    at async load (src/routes/+page.server.ts:6:21)
    at async fn (.../@sveltejs/kit/src/runtime/server/page/load_data.js:101:19)
    at async load_server_data (.../@sveltejs/kit/src/runtime/server/page/load_data.js:91:17)
    at async eval (.../@sveltejs/kit/src/runtime/server/page/index.js:207:26)

System Info

System:
    OS: Windows 11 10.0.26200
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
    Memory: 1.42 GB / 15.71 GB
  Binaries:
    Node: 24.17.0 - C:\nvm4w\nodejs\node.EXE
    npm: 11.13.0 - C:\nvm4w\nodejs\npm.CMD
    pnpm: 11.20.0 - C:\Users\Lukeh\AppData\Local\pnpm\pnpm.CMD
    bun: 1.3.14 - C:\Users\Lukeh\.bun\bin\bun.EXE
  Browsers:
    Edge: Chromium (123.0.2420.65)
    Firefox: 150.0.1 - C:\Program Files\Mozilla Firefox\firefox.exe
    Internet Explorer: 11.0.26100.8115
  npmPackages:
    @sveltejs/adapter-cloudflare: ^7.2.9 => 7.2.9 
    @sveltejs/kit: ^2.70.2 => 2.70.2 
    @sveltejs/vite-plugin-svelte: ^7.2.0 => 7.2.0 
    svelte: ^5.56.8 => 5.56.8 
    vite: ^8.2.0 => 8.2.0

Severity

serious, but there is a workaround

Additional Information

• Confirmed not a remote: true binding issue in general — R2 and queue
  bindings with remote: true in the same project's wrangler.jsonc were
  not implicated (not exercised by the failing request path, but worth
  noting as scope).
• Workaround in use: dropped remote: true on the D1 binding for dev,
  applying schema locally instead (wrangler d1 execute <db> --local --file=./schema.sql) — local D1 emulation works correctly, only the
  remote-binding proxy path used by adapter-cloudflare's dev integration is
  affected.
• Possibly related/upstream: this may actually belong in
  cloudflare/workers-sdk (wrangler's getPlatformProxy/mixed-mode remote
  bindings) rather than SvelteKit itself — filing here first since the
  failure only surfaces through @sveltejs/adapter-cloudflare's dev
  integration; happy to cross-post if maintainers point that way.

Start with the linked reproduction and trace the failing request from src/lib/server/db.ts and +page.server.ts through adapter-cloudflare's dev integration and Wrangler's getPlatformProxy remote-bindings path. Compare vite dev with local D1, the Wrangler CLI, and production; done means remote D1 queries return a valid response under vite dev or the issue is confirmed as belonging upstream in workers-sdk.