[BUG][typescript-node] The same response type deserialized for all HTTP statuses

[quezak]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Bounty to sponsor the fix (example)

Description

Use case:

• on HTTP 200 OK, API returns a TestResponse
• on any (or specific) errors, API returns an ErrorResponse

Bug: the client generated with typescript-node always tries to deserialize the successful type only. Because the ObjectDeserializer only deserializes known fields, the generated code rejects with an empty body, and with no access to the actual error body.

Here's the offending code snippet generated (it's the same for all paths in spec):

        return new Promise<{ response: http.IncomingMessage; body: TestResponse;  }>((resolve, reject) => {
            localVarRequest(localVarRequestOptions, (error, response, body) => {
                if (error) {
                    reject(error);
                } else {
                    // This will deserialize `{}` for an `ErrorResponse`!
                    body = ObjectSerializer.deserialize(body, "TestResponse");
                    if (response.statusCode && response.statusCode >= 200 && response.statusCode <= 299) {
                        resolve({ response: response, body: body });
                    } else {
                        reject({ response: response, body: body });
                    }
                }
            });
        });

Fix proposition at the bottom.

openapi-generator version

I think all, I've tested:

• 4.0.0
• 4.1.0-20190515.034101-2
• 5.0.0-20190515.034058-2

OpenAPI declaration file content or url

full example on gist

The most important part -- I've tried the second response with default, 500 and 5XX keys, all yielding the same result.

                "responses": {
                    "200": {
                        "description": "Successful operation",
                        "schema": { "$ref": "#/definitions/TestResponse" }
                    },
                    "default": {
                        "description": "Unexpected error",
                        "schema": { "$ref": "#/definitions/ErrorResponse" }
                    }
                }

Command line used for generation

java -jar ~/pkg/openapi-generator-cli-5.0.0-20190515.034058-2.jar generate -i test.json -g typescript-node -D supportsES6=true

Steps to reproduce

1. Generate the clients
2. Inspect the generated code :)

Suggest a fix

The body should be deserialized to a proper type, depending on the HTTP status code. For example:

        return new Promise<{ response: http.IncomingMessage; body: TestResponse;  }>((resolve, reject) => {
            localVarRequest(localVarRequestOptions, (error, response, rawBody) => {
                if (error) {
                    reject(error);
                } else {
                    if (response.statusCode && response.statusCode === 200) {
                        const body = ObjectSerializer.deserialize(body, "TestResponse");
                        resolve({ response, body });
                    // Note 1: If I specified a response for "5XX" status, this should be also checked, but here I used "default"
                    // else if (response.statusCode && response.statusCode >= 500 && response.statusCode <= 599) {
                    } else {
                        const body = ObjectSerializer.deserialize(body, "ErrorResponse");
                        reject({ response, body });
                    }
                    // Note 2: If the spec doesn't have a "default" response key, the response type is not known,
                    // then it probably should `reject({ response, body: rawBody })`
                }
            });
        });

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[quezak]

Just a quick update, in the latest 5.0.0 snapshots the reject variant throws an HttpError instead of a plain object, but still with the same body parameter -- which will be empty if the error response type is different (which is true 99% of the time).

Posting this just FYI, I know the typescript generators are under a rewrite, waiting patiently for them to be done 😃

            return new Promise<{ response: http.IncomingMessage; body: TestResponse;  }>((resolve, reject) => {
                localVarRequest(localVarRequestOptions, (error, response, body) => {
                    if (error) {
                        reject(error);
                    } else {
                        body = ObjectSerializer.deserialize(body, "TestResponse");
                        if (response.statusCode && response.statusCode >= 200 && response.statusCode <= 299) {
                            resolve({ response: response, body: body });
                        } else {
                            reject(new HttpError(response, body, response.statusCode));
                        }
                    }
                });
            });

[jaydeep987]

Not a solution but just kind of thing I found with ObjectSerializer. (typescript only generator)
I like framework agnostic approach. But in js world, I think tightly bound code is bit problematic. Like the pure typescript generator produces models and response is deserialized to match model (which as that attributemap).

ObjectSerializer.deserialize(ObjectSerializer.parse(await response.body.text(), contentType), "MyModel", "")

There are higher chances that openapi schema file is not up to date, and I am not gonna wait for the backend to update their spec. (sometimes it is third party company). And so, the model also wont have attributes which may be present in response.
So I would like approach which definitely match response to attribute map, but also provide additional response as props like accessible.
Using typescrip-xxx (like typescript-fetch etc) is not solution, its either not framework agnostic or none of them supports authorization.

[dever4eg]

Here is the workaround

const deserialize = ObjectSerializer.deserialize;
ObjectSerializer.deserialize = (data: any, type: string) => {
  if (data?.status === 'Failure') {
    return data;
  }
  eturn deserialize(data, type);
}