err.code type changes from 'string' to 'number'.

[scschl]

Thanks for stopping by to let us know something could be better!

PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.

1. Is this a client library issue or a product issue?
   This is the client library for . We will only be able to assist with issues that pertain to the behaviors of this library. If the issue you're experiencing is due to the behavior of the product itself, please visit the Support page to reach the most relevant engineers.

2. Did someone already solve this?

• Search the issues already opened: https://github.com/googleapis/google-auth-library-nodejs/issues
• Search the issues on our "catch-all" repository: https://github.com/googleapis/google-cloud-node
• Search or ask on StackOverflow (engineers monitor these tags): http://stackoverflow.com/questions/tagged/google-cloud-platform+node.js

3. Do you have a support contract?
   Please create an issue in the support console to ensure a timely response.

If the support paths suggested above still do not result in a resolution, please provide the following details.

Environment details

• OS: Windows 10.0.18362
• Node.js version: 12.13.0
• npm version: 6.12.0
• google-auth-library version: 6.1.1.

Steps to reproduce

1. Call google.classroom("v1").courses.list(), or any related API (courses.teacher, courses.student, etc.)
2. Keep calling until a quota threshold is reached (should get a 429 error code).
3. Look at the typeof the error.code returned. It will be a 'number', but should be a 'string'.

Looks like
err.code = body.error.code;
around line 95 in processError() in transporters.js needs to ensure the assigned value is a string.

Line 112 handles this by calling toString(). Might be other lines that need to ensure the code field is a string type.

Making sure to follow these steps will guarantee the quickest resolution possible.

Thanks!

[bcoe]

@scschl I would expect error.code to be a number, is the problem that the types indicate that it's a string?

[scschl]

Yes, it seems inconsistent that sometimes 'code' is a string and other times it's a 'number'. The types indicate it should be a string:
I'm assuming that the error returned is of type RequestError (correct me if that's wrong):

export interface RequestError extends GaxiosError {
errors: Error[];
}

export declare class GaxiosError<T = any> extends Error {
code?: string;
response?: GaxiosResponse;
config: GaxiosOptions;
constructor(message: string, options: GaxiosOptions, response: GaxiosResponse);
}

[scschl]

Also, if it's expected to be a number, why is it explicitly converted to a string if the status is >=400 ?

else if (res && res.status >= 400) {
// Consider all 4xx and 5xx responses errors.
err.message = body;
err.code = res.status.toString();

[sofisl]

Hi there, thanks for submitting this bug! I can confirm that this is happening. Since GaxiosError expects code to be a string, it seems like this is indeed a bug.

I've addressed it in #1165.

[bcoe]

@scschl we intend to address this issue, but all the fixes we could think of would be a breaking change for many of our libraries.

Are you able to workaround the issue today by running Number(err.code), and in the next major release for our libraries we will sort out these conversion issues?