Three Wrangler and Vite plugin failure modes that hid the real error

Good tooling fails loudly and truthfully. Three recent fixes in cloudflare/workers-sdk are a nice reminder of what happens when it does not: the real failure happens, then something unrelated gets reported instead.

1. A SyntaxError that replaced the real failure

When the Vite plugin for Cloudflare asked Miniflare for a Worker's export types and Miniflare answered with a non-success response, the plugin tried to parse the plain-text error body as JSON. The result was a SyntaxError that had nothing to do with the actual problem.

The fix (PR #15407) is the boring, correct one: check the HTTP status before you parse, and when it is not a success, report the Worker name, the status and the original response body. Successful responses behave exactly as before.

The general rule: never await res.json() before you have looked at res.ok. A parse error is a symptom you created yourself, and it buries the cause.

2. Uploading a version the API was always going to reject

wrangler versions upload would happily upload assets and a Worker version, and only then find out that the API rejected it with error 10211, because the Worker had a Durable Object migration that was still pending.

The fix (PR #15411) makes the command detect an actually pending migration using the existing remote-aware migration resolution, and fail locally with guidance to run wrangler deploy instead. Already-applied migration history and dry runs are unchanged.

The general rule: if you can know a request will be rejected, say so before doing the expensive part of the work, and say what to do next.

3. Provisioning that rewrote a path it did not own

With a redirected config (the kind the Vite plugin generates), provisioning a D1 database wrote the complete generated binding back into the original user config. Generated configs can contain paths rebased relative to their own location, so a user-authored migrations_dir was replaced with a path that is invalid in the source config.

The fix (PR #15517) changes the writeback to start from the binding in the active section of the original config and overlay only the newly provisioned resource identifier. For named environments the lookup and writeback are scoped to the target environment when that section exists, and the original binding array order is kept so positional config patches still line up.

The general rule: when you write back into a file a human authored, change only what you created. Round-tripping a whole generated object is how you silently destroy someone's settings.

The shape they share

All three bugs are about honesty at the boundary: report the real status, refuse early with a reason, and touch only your own data. None of them is clever. All of them are the difference between a five-second diagnosis and a lost afternoon.

If you hit any of these in the wild, the PR numbers above are in cloudflare/workers-sdk and the linked issues have the original reports.