Invalid code generated when response description is a number

[Ross Tuck]

Description

When generating a client via the createClient function, if the response schema has only a number for the "description" string, then the generated error code is invalid.

Given the following error response body on a "create access token" action (this bug manifests with both small and complex responses but cutting it down to the bare minimum here for clarity):

"400": {
    "description": "400"
}

Then the following code is generated in services.gen.ts:

export const createAccessToken = (data: CreateAccessTokenData): CancelablePromise<CreateAccessTokenResponse> => { return __request(OpenAPI, {
    method: 'POST',
    url: '/v1/oauth2/token',
    headers: {
        'Cache-Control': data.cacheControl,
        'Content-Type': data.contentType
    },
    body: data.requestBody,
    mediaType: 'application/json',
    errors: {
        400       // <--- Only 400 here is invalid, it needs to have the value specified and can not be short handed
    }
}); };

Conversely, if I change the response schema to a full string:

"400": {
    "description": "Error 400"
}

Then I receive correctly generated code:

export const createAccessToken = (data: CreateAccessTokenData): CancelablePromise<CreateAccessTokenResponse> => { return __request(OpenAPI, {
    method: 'POST',
    url: '/v1/oauth2/token',
    headers: {
        'Cache-Control': data.cacheControl,
        'Content-Type': data.contentType
    },
    body: data.requestBody,
    mediaType: 'application/json',
    errors: {
        400: 'Error 400'
    }
}); };

I went through the codebase to try and narrow this down in hopes of creating a test or a PR but without any luck.

However, I suspect it's based in the createObjectType function, looking at the code paths there but I can't prove it.

OpenAPI specification (optional)

No response

Configuration

This appears with both asClass / name turned on but also with no config options at all, beyond input/output.

System information (optional)

No response

[Lubos]

Hey @rosstuck, thanks for reporting. Are you able to switch to the new Fetch API client?

[Ross Tuck]

Hi @mrlubos, thanks for the quick response! I've switched over to the new Fetch API Client and tried it in both circumstances, without any problems.

This is a new integration so I can proceed forward with this for my own work. :)

[Lubos]

Thanks! I'll keep this open as it will still need to be fixed for the old clients