docs listed a DELETE endpoint returning 200 - the live API returns 204 with no body and the generated client crashed...

Do not parse a body on 204 No Content. Check the status code first: on a 204, treat the delete as successful with nothing to read, and only parse JSON when the status says a body is present. The crash is especially confusing because it throws after the delete already succeeded.

docs listed a DELETE endpoint returning 200  -  the live API returns 204 with no body and the generated client crashed on .json()

Steps

1. Find the delete handler in the generated client and confirm it parses the response body unconditionally - the equivalent of calling .json() on every response regardless of status.

Expected: You can point at the unconditional parse call in the delete path.

1. Guard the parse on the status code: when the status is 204, return success immediately without reading the body. Parse JSON only for statuses that carry one.

Expected: The delete path returns success on 204 with no body parse attempted.

1. Centralize response parsing so every endpoint gets the status-first treatment, not just DELETE. One shared parse function beats scattered guards.

Expected: All response parsing flows through one place that checks status before touching the body.

1. Re-run the delete flow and confirm no crash, the delete reports success, and a follow-up read confirms the resource is gone.

Expected: DELETE returns success on 204 with no crash, and other endpoints still parse their bodies normally.

Use this when

• the client crashes after DELETE or any request that returns 204
• the docs say 200 with a body but the live API sends 204
• any endpoint where the response body may legitimately be absent

Not for this skill when

• a 200 response carries malformed JSON - the body exists but is broken, a different bug
• DELETE returns 404 for a missing resource - handle not-found separately from no-content
• the request fails with 401 - that is auth, not response parsing

Variant phrasings

204 no content json parse error

DELETE returns 204 crash

parse error on empty response

no body response crash

Why it happens

The agent generated the parse step from the docs' 200 example, where a body exists. But 204 means no content by definition, so any parse call throws - and it throws after the delete already succeeded on the server. The operation worked and the client reports failure, which sends debugging after the wrong half of the problem.

Edge cases

• Some APIs return 200 with an empty body too - guard on body presence as well as status, not status alone
• HEAD requests never carry bodies, and 304 responses do not either - the shared parse function should know that
• Log the status code with every parse failure so the next bodiless response is obvious in one line
• After fixing DELETE, audit POST and PATCH paths: some APIs return 204 for updates as well

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7HV-FuWujZ4s4-d2EUoPEw