Error when fetching endpoint that's not json

[newholder]

Description

When fetching an endpoint that returns other than json and you forget to set parseAs and the endpoint return OK, it will throw an error.

If i'm not mistaken, this code govern how result are parsed

// parse response (falling back to .text() when necessary)
    if (response.ok) {
      // if "stream", skip parsing entirely
      if (parseAs === "stream") {
        return { data: response.body, response };
      }
      return { data: await response[parseAs](), response };
    }

    // handle errors
    let error = await response.text();
    try {
      error = JSON.parse(error); // attempt to parse as JSON
    } catch {
      // noop
    }
    return { error, response };

this line

 if (response.ok) {
      // if "stream", skip parsing entirely
      if (parseAs === "stream") {
        return { data: response.body, response };
      }
      return { data: await response[parseAs](), response };
    }

checks if fetch result are ok, and if it is, check if parseAs set to stream, skip parsing and return the body. If it isn't stream you parse it by calling the built-in function with the same name as parseAs and it defaulted to json. This could fail, and i think this exception is uncaught. Is this expected behaviour?

Reproduction

Create an openapi endpoint that return text, create client similar to getting started tutorial and try to fetch that endpoint without setting parseAs

Expected result

Is there a way to parse it based on Content-Type defined in the schema?

Checklist

• I’m willing to open a PR (see CONTRIBUTING.md)

[drwpow]

Is there a way to parse it based on Content-Type defined in the schema?

No; your schema contains only types, and you must provide a runtime value to know how to parse your schema. Even if, somehow, we could throw a type error that lets you know this may be wrong, some people still may want to set parseAs to something different depending on their usecase (e.g. they may want to parse a JSON response as a stream in case they want to parse it incrementally).

This isn’t a bug; this is working as-intended. Most people consume their endpoints as JSON, so throwing an error on everything not-JSON is intended behavior.

[sethetter]

We're running into this today. We are able to get around it by passing parseAs: "stream" but that feels weird because we're not actually parsing anything, it's just an implicit way to tell the client not to try and parse the response.

In our case, the response is completely empty, and is supposed to be empty. The spec specifies it as such. I would expect the client to know that and not attempt to parse a JSON response when the spec itself says the response will be empty.

I know the generated clients are driven entirely by the generated types, so I'm not sure how easy it is to get that type information into the runtime behavior here. But as a user of this library, it feels weird that that type for the response is never, but the implementation is trying to parse something anyways. Feels like a mismatch!

[drwpow]

@sethetter appreciate you weighing in! Many folks agree with you. It’s a design limitation currently, but the maintainers (including myself) are discussing the idea of introducing some codegen to openapi-fetch in a breaking change to make this smoother. There are always more users that don’t speak up than do, so input is appreciated! The overall sentiment we’ve been getting is “we’d accept a little more weight, and the tiniest bit of runtime overhead for less boilerplate” and we’re listening

[cbix]

Same issue here. I understand it's a limitation of "only generating types" that you currently can't implement logic based on the schema. In case it helps, our schema declares different content types and I'd love a generated client to consider these:

"responses": {
  "200": {
    "description": "Successful Response",
    "content": {
      "text/plain": {
        "schema": {
          "type": "string"
        }
      }
    }
  },
  "422": {
    "description": "Validation Error",
    "content": {
      "application/json": {
        "schema": {
          "$ref": "#/components/schemas/HTTPValidationError"
        }
      }
    }
  }
}

Checking the response content-type header before attempting to parse JSON could be a first step.