fix(core): treat empty 2xx response bodies as no-content

[Butch78]

Some Cloudflare endpoints return a success status with an empty body instead of 204 No Content. The clearest case is the Workers custom-domain delete (DELETE /accounts/{account_id}/workers/domains/{domain_id}), which replies 200 with no body — but the OpenAPI-generated DeleteDomainResponse schema still declares a { errors, messages, success: true } envelope (per the documented response). The client only short-circuits the response decode for 204 and for Void-typed operations, so an empty 200 falls through to the JSON decode and fails to satisfy the declared schema.

On its own that is an instant, deterministic error — but a caller that retries on transient errors (for example alchemy's default retry policy) classifies the decode failure as retryable and retries it with exponential backoff, turning it into a multi-hour silent hang on every deploy or destroy that attaches or detaches a custom domain. A direct request to the same endpoint returns a clean 200 with an empty body, confirming the API is healthy and the gap is purely client-side.

Fix

Treat an empty body on a successful DELETE response as no-content, mirroring the existing 204 handling, before attempting to decode it.

Scoped to DELETE (see review discussion) so that an unexpectedly-empty GET/POST/PUT still fails the decode and retries, rather than being silently swallowed — that is the transient-error case we do not want to mask. DELETE callers already receive undefined on the 204/Void paths, so the behavior is consistent, and because the gate only fires on an empty body, DELETEs that legitimately return an envelope (e.g. DNS record delete -> { result: { id } }) are unaffected.

if (
  method === "DELETE" &&
  (rawBody === "" || rawBody === undefined || rawBody === null)
) {
  return outputSchema.ast._tag === "Unknown" ? "" : undefined;
}

References

• Cloudflare API — Workers custom-domain delete (documents 200 + { errors, messages, success }, while the live endpoint returns an empty 200): https://developers.cloudflare.com/api/resources/workers/subresources/domains/methods/delete/

[sam-goodwin]

Null response can be a transient error is some cases. Not sure if this is safe? Do we need to instead patch specific APIs known to do this?

[Butch78]

Good call, that was too broad. Pushed 56b6cb9 to scope the short-circuit to DELETE only.

Reasoning:

• The transient-empty risk you flagged is real for reads/creates (a GET/POST/PUT that comes back unexpectedly empty should fail the decode and retry, not be silently swallowed). Those paths are now untouched, so they keep failing loudly.
• The only case we actually need to absorb is a DELETE whose declared schema is a 200 envelope but whose live response is an empty 200. DELETE callers already receive undefined on the existing 204/Void paths, so returning undefined here is consistent.
• The gate only fires on an empty body, so DELETEs that do return a real envelope (e.g. DNS record delete -> { result: { id } }) decode normally and are unaffected. It is specifically the empty-body case that gets treated as no-content.

On "patch specific APIs instead": the trouble is the discrepancy is between the documented contract and the live wire behavior, not something visible in the spec. The Workers custom-domain delete is documented as 200 + { errors, messages, success }:

• https://developers.cloudflare.com/api/resources/workers/subresources/domains/methods/delete/

...so the generator faithfully emits that envelope, while the live endpoint returns an empty 200 (a direct request to the same endpoint returns a clean 200 with no body). A per-operation allowlist would mean hand-maintaining a list of these as we discover them, with generator support to thread it through. Gating on DELETE + empty-body is a smaller, self-correcting surface that covers the class without masking the dangerous read/create case. Happy to switch to an allowlist if you would rather be fully explicit.