Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Check the HTTP status code for JSON responses

Open
  • Is something wrong?
#469 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

@mvanhorn is already working on this.

Since Oct 14, 2026.

  • #471 by @mvanhorn — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
swift
Domain
api

Research direction

Start with Sources/OpenAI/Private/JSONResponseDecoder.swift and URLResponseHandler, then compare the existing status handling in StreamingSession and throwIfErrorStatus. Check relaxed parsing behavior for supported providers and add non-2xx tests for completion-handler, async, and Combine requests, including API and non-API error bodies. Done when all four response paths handle transport errors and status codes consistently and the CHANGELOG describes the changed errors.

Written by the indexing model from the issue text.

Description

JSON requests never check the HTTP status code. They seem to handle API errors only because JSONResponseDecoder falls back to decoding an API error when the expected result type fails to decode (Sources/OpenAI/Private/JSONResponseDecoder.swift). That fallback misses two cases:

  • The error body isn't an API error, such as an HTML page from a proxy or gateway. The caller gets a DecodingError about the expected type instead of an error carrying the status code.
  • The error body decodes as the expected type. With .relaxed parsing, which fills in missing required fields, an error body could decode into a result with default values and be returned as a success.

#401 adds a status check for responses read as raw data (files.content(id:) and audioCreateSpeech), in URLResponseHandler.throwIfErrorStatus. It throws the decoded APIErrorResponse for a status of 400 or above, falling back to OpenAIError.statusError, as StreamingSession already does. JSON responses were left out because changing them affects every endpoint.

Proposal

  • Route all four URLResponseHandler methods (JSON and raw, with and without an error: parameter) through one function, probably unwrap with the response added, that throws a transport error first and then checks the status. That way completion-handler, async and Combine requests behave the same.
  • Check that providers supported through .relaxed parsing still work, in particular whether any of them return successful responses with a status of 400 or above, or error bodies in a shape JSONResponseErrorDecoder doesn't know.
  • Add tests with a non-2xx status and an error body, and with a non-API body, for all three flavours.

This changes what JSON requests throw in some error cases (OpenAIError.statusError instead of a DecodingError), so it needs a CHANGELOG entry.

Dominant language
Swift
Stars
2.9k
Forks
519
Avg merge
4d 9h
Merged PRs (30d)
13

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MacPaw/OpenAI

All issues in MacPaw/OpenAI

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.