Response.pasred and non-200 responses

[naddeoa]

From manual testing, it looks like the generated clients only attempt to parse the response body if the return code is 200. I have an endpoint that can return a 400 status code, in which case the body will be the same type as if it were a 200 response code, but it will contain extra information about what went wrong. The point of this endpoint is to run a validation, returning 200 if the validation passes and 400 if it doesn't.

Right now, consumers would have to avoid the Response.parsed field all the time because they have to manually deserialize the response for 400 cases anyway, which isn't nice code.

What's the recommendation here? Should I use templates/manually update the generated parse code to include 400 error codes? Did I do something in my openapi schema that resulted in this behavior by mistake?

[dbanty]

The parsed field should be a union of every possible response type if there is more than one response schema. A quick test with this path:

"/responses/multiple-statuses": {
  "get": {
    "responses": {
      "200": {
        "description": "Success",
        "content": {
          "application/json": {
            "schema": {
              "type": "object",
              "title": "Success",
              "properties": {
                "success": {
                  "type": "boolean"
                }
              }
            }
          }
        }
      },
      "201": {
        "description": "Created",
        "content": {
          "application/json": {
            "schema": {
              "type": "object",
              "title": "Created",
              "properties": {
                "created": {
                  "type": "boolean"
                }
              }
            }
          }
        }
      }
    }
  }
}

Generates two classes: GetResponsesMultipleStatusesCreated and GetResponsesMultipleStatusesSuccess. The return type of sync_detailed is Response[Union[GetResponsesMultipleStatusesCreated, GetResponsesMultipleStatusesSuccess]], meaning response.parsed will be that union type.

So if there are cases where those are not generated, I think that's a bug.

[naddeoa]

In my case, my parsed field is of type HTTPValidationError | ValidationReport | None, so I think the typing is correct. The generated code in question is

def _parse_response(
    *, client: Union[AuthenticatedClient, Client], response: httpx.Response
) -> Optional[Union[HTTPValidationError, ValidationReport]]:

    if response.status_code == HTTPStatus.OK:
        response_200 = ValidationReport.from_dict(response.json())

        return response_200
    if response.status_code == HTTPStatus.UNPROCESSABLE_ENTITY:
        response_422 = HTTPValidationError.from_dict(response.json())

        return response_422
    if client.raise_on_unexpected_status:
        raise errors.UnexpectedStatus(response.status_code, response.content)
    else:
        return None

The actual parsing only happens when the status code is either 200 or 422, otherwise None is returned.

[naddeoa]

or are you saying that I need to explicitly document the return code in the schema (I'll try that now)

[dbanty]

Yeah, it will only attempt to parse a model from a known status code. If the status code's schema isn't documented, it won't know what to parse. There is the default special case in OpenAPI, but that isn't implemented yet (see #832)