Request returning null in data and error when no response type defined

[cesnietor]

Hi, I'm encountering an issue when defining a 2xx response code without response type defined. like:

...
      responses:
        200:
          description: A successful response.
        #   schema:
        #     $ref: "#/definitions/performResponse"
        default:
          description: Generic error response.
          schema:
            $ref: "#/definitions/error"

When I generate the code like: npx swagger-typescript-api -p ./swagger.yml -o ./mypath -n myfile.ts

The request is ALWAYS returning null for both "data" and "error". (see image(I added a console.log()))

If I define a response type (by uncomenting the lines there) then there is something in the "data" or "error" but not sure why and if this might be a bug.

[cesnietor]

We found a way of catching it by doing :

.catch(async (res: HttpResponse<void, Error>) => {
        const err = (await res.json()) as Error;

when handling the response.

The content is in the body but it was not getting deserialized correctly. This is a workaround but works, so sharing in case it's helpful for someone.

[joaomantovani]

@cesnietor I'm facing the same issue and your workaround is working.

I'll watch this topic too see if anyone has a definitive solution

[ReangeloJ]

Encountering the exact same issue here!

[ReangeloJ]

Workaround to get the data for me was by doing:

const res = api.call().then(function(response) {
    return response.json();
}).then(function(data) {
    console.log(data); 
});

And as stated above you can use .catch to get the error.

[MbBrainz]

Im also encountering this, however i have a schema defined as follows. And it only happen when i use the flag --extract-response-body. Without that flag, it works.

I used the following command to generate the api client and types.

sta -p api-swagger.yml -r -n api.ts --api-class-name SkipApi --extract-request-params --extract-request-body --extract-response-body --extract-response-error --modular

   responses:
        '200':
          description:
            The IBC hops before and after the swap, and the swap and fee swap information.
          content:
            application/json:
              example:
                preSwapHops:
                  - port: transfer
                    channel: channel-78
                    ...
              schema:
                type: object
                properties:
                  preHopSwaps:
                    type: array
                    items:
                      $ref: '#/components/schemas/IBCHop'
                  postHopSwaps:
                    type: array
                    items:
                      $ref: '#/components/schemas/IBCHop'
                  chainIds:
                    type: array
                    items:
                      type: string
                  sourceAsset:
                    $ref: '#/components/schemas/IBCDenom'
                  destAsset:
                    $ref: '#/components/schemas/IBCDenom'
                  amountIn:
                    type: string
                  userSwap:
                    $ref: '#/components/schemas/SwapIn'
                  userSwapAmountOut:
                    type: string
                  feeSwap:
                    $ref: '#/components/schemas/SwapExactCoinOut'
                    nullable: true
                  swapChainId:
                    type: string
                  totalAffiliateFee:
                    type: string

[solcik]

I encounter this also, and found out, that it is due to missing format: 'json' when using --extract-response-body

[Amar97]

Our fix was to not use --extract-response-body and to make sure your api spec has the right properties.

E.g. in spring boot, we had to add default-produces-media-type: application/json in our application.yml

[squivix]

Also encountering this, even without using --extract-response-body.

I've got an endpoint with either a 204 or 400 response. The 204 is empty and has no content, while the 400 has content application/json and a schema. Here's the simple specs:

{
  "responses": {
    "204": {
      "description": "No Content"
    },
    "400": {
      "description": "Bad Request\n\nSome fields are invalid or required fields are missing.",
      "content": {
        "application/json": {
          "schema": {
            "type": "object",
            "properties": {
              "code": {
                "type": "integer",
                "enum": [
                  400
                ]
              },
              "status": {
                "type": "string",
                "enum": [
                  "Bad Request"
                ]
              },
              "message": {
                "type": "string"
              },
              "details": {
                "type": "string"
              },
              "fields": {
                "type": "object",
                "minProperties": 1
              }
            },
            "required": [
              "code",
              "status",
              "message",
              "details"
            ]
          }
        }
      }
    }
  }
}

The route params format is generated as undefined:

    routeId: (
      data: {
//....
      },
      params: RequestParams = {},
    ) =>
      this.request<
        void,
        | {
            code: 400;
            status: "Bad Request";
            message: string;
            details: string;
            fields?: object;
          }
      >({
        path: `/path/to/route/`,
        method: "PUT",
        body: data,
        secure: true,
        type: ContentType.Json,
       //Here format is undefined, even though type is ContentType.Json.
        ...params,
      }),

As a result error comes out as null in the response.

It seems like having an error response with content application/json doesn't matter, only 2XX responses seem to affect it. If I add content.application/json to the 204 response, it works and gives it a json format, but I don't wanna mess up my specs.

Any way around this besides changing the specs or getting around the client?