How to handle "`default:` response error handling" like in the petstore v3

[skirsten]

As one can see in the example petstore v3 the errors are handled explicitly using default:

responses:
  '200':
    description: A paged array of pets
    headers:
      x-next:
        description: A link to the next page of responses
        schema:
          type: string
    content:
      application/json:    
        schema:
          $ref: "#/components/schemas/Pets"
  default:
    description: unexpected error
    content:
      application/json:
        schema:
          $ref: "#/components/schemas/Error"

other code generators that I am currently using are fine with this and even expect it (e.g. https://github.com/deepmap/oapi-codegen).

With this project, this results in the Error type being added to the response type. This is the expected behavior.

CancelablePromise<Array<Pet> | Error>

The problem is

If I understand correctly, due to the integrated error handling, this Error will never be returned. How can I either

1. ignore the default response using something like x-ts-emit: false or x-ts-ignore: true
2. ignore all default responses (only for this generator)
3. turn of the existing error handling and implement my own to get rid of the Error type (would prefer to avoid this)

And no, I cannot just remove it from the OpenAPI spec. This would break the code generators for other languages.

Also something I noticed: If a 204 status code is expected and the default is Error the null, undefined or void for the 204 is missing from the response type:

CancelablePromise<Error>

I would expect this to be

CancelablePromise<void | Error>

Any help and ideas are appreciated.

[skirsten]

I fixed the problem for now by pre-processing the input spec using yq:

yq 'del(.paths.[].[].responses.default)' openapi.yaml | openapi --input /dev/stdin ...

[MarcelAlersTypeflow]

The problem is here: getOperationResponseCode.ts

if (value === 'default') {
    return 200;
}

default is interpreted as 200. But default is meant to be all not defined status codes, explained here: swagger.io