[P1][Review] Accept successful empty 204 responses instead of raising JSONDecodeError

[karlwaldman]

Review-only / approval gate

No implementation, PR merge, package publication or production mutation until the owner approves the full sprint plan.

Evidence

Reviewed main 31b8d80686495c5d6dcac0846d6e5a2c8d4bce8b.

oilpriceapi/client.py request/request_with_headers and async_client.py request parse every 2xx with response.json(). A mocked 204 through client.webhooks.delete('fixture-id') raises JSONDecodeError. The backend v1/webhooks_controller.rb destroy actually returns head :no_content. The deletion can succeed while the caller is told it failed.

Preferred smallest change

Add a narrow no-content response path in the existing transport. Keep delete's documented return contract; do not treat malformed nonempty 200 JSON as success. Remove duplicated decoding only where needed.

Acceptance / negative-path tests

Sync webhook deletion, corresponding async deletion, request_with_headers: 204 empty succeeds without retry; malformed 200 remains an error; 401/403 preserve typed errors. Verify against a disposable fixture, not production deletes.

Risk and PR gate

P1 customer-visible mutation/recovery contract; Saturday.
One focused issue PR; independent adversarial review must challenge deletion safety, public compatibility, failure recovery and whether a smaller deletion suffices. Include red/green test evidence and packed/installable artifact proof for any published SDK/MCP change. Merge only in the approved priority order after reviewer objections are resolved. Do not publish a breaking change as a patch. If already fixed at execution time, record evidence and skip without a cosmetic PR.

[karlwaldman]

Adversarial sprint admission — rank 18/70

Scheduled Saturday, 2026-09-05 (America/New_York) in the approval-gated seven-night plan. Planning only; no implementation or merge yet.

Narrow outcome: Accept successful 204 deletions.

Required issue → PR → independent review → ordered merge evidence

• Reproduce on the execution-day main and confirm exact files/callers; the review baseline was the current-main SHA recorded in this issue. If already fixed or unnecessary, record proof and close without a cosmetic PR.
• Record why deletion alone does or does not solve this; delete redundant code before adding a helper/guard/automation.
• A focused failing regression/fixture first where practical; test the relevant malformed, absent, stale, rejected or timeout path as well as success. No production customer mutations or raw-secret evidence.
• One independently revertible PR, containing the narrow correction and targeted tests; no unrelated cleanup. Explain public/API compatibility and rollback.
• Independent adversarial reviewer tests the failure case, challenges the assumptions and simpler alternatives, and resolves every blocking finding.
• Refresh against the actual merge base and rerun checks before merging in this plan's numbered order. Preserve all existing required checks; no bypass to hit ten.
• Link merge SHA plus approved deployed/published artifact and post-release proof where relevant; otherwise mark release pending rather than claiming shipped.

Risk window: High-risk window, including prerequisites to the related high-risk correction.

[karlwaldman]

Coverage-audit revision — current sprint admission

Plan v2: oilpriceapi-api#8015 supersedes earlier scheduling comments. Rank 27/70; Sunday, 2026-09-06, America/New_York. Low/medium-risk only; reclassify to a Friday/Saturday slot if boundary/compatibility risk is higher.

Intended outcome: Accept successful 204 deletions.

Coverage ledger: #8056. Inventory/pattern screening is complete; exhaustive semantic/runtime sign-off is not. Before implementation, review the complete affected file set and callers, revalidate against current main, supply the missing negative-path proof, and retain prior scope corrections. Prefer deletion, then simplification; correct behavior needs no PR.

No implementation is approved yet. After Karl approves: focused reversible PR → independent adversarial review → passing affected checks → merge in plan order → separately approved release/publish and artifact/customer-path verification. Maximum ten planned slots per night, not ten forced merges. If the dated window elapses before approval, re-anchor the calendar rather than backdate execution.