Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Check the HTTP status code for JSON responses

Abierto
  • ¿Algo no está bien?
#469 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

@mvanhorn ya está trabajando en esto.

Desde el 14/10/2026.

  • #471 de @mvanhorn — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
swift
Área
api

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Swift
Estrellas
2.9k
Forks
519
Merge medio
4 d 9 h
PR fusionados (30 d)
13

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MacPaw/OpenAI

Todos los issues de MacPaw/OpenAI

Issues similares

Más issues de Swift

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.