Skip to content

Schema$Userinfo interface returns optional values #3151

Closed

Description

@CoolTechYT

Environment details

  • OS: MacOS
  • Node.js version: 16.15.0
  • npm version: 8.19.2
  • googleapis version: ^110.0.0

Steps to reproduce

  1. Check Schema$Userinfo interface (from oauth2.userinfo.get())
  2. Confirm the exported interface properties are all optional
  export interface Schema$Userinfo {
        /**
         * The user's email address.
         */
        email?: string | null;
        /**
         * The user's last name.
         */
        family_name?: string | null;
        /**
         * The user's gender.
         */
        gender?: string | null;
        /**
         * The user's first name.
         */
        given_name?: string | null;
        /**
         * The hosted domain e.g. example.com if the user is Google apps user.
         */
        hd?: string | null;
        /**
         * The obfuscated ID of the user.
         */
        id?: string | null;
        /**
         * URL of the profile page.
         */
        link?: string | null;
        /**
         * The user's preferred locale.
         */
        locale?: string | null;
        /**
         * The user's full name.
         */
        name?: string | null;
        /**
         * URL of the user's picture image.
         */
        picture?: string | null;
        /**
         * Boolean flag which is true if the email address is verified. Always verified because we only return the user's primary email address.
         */
        verified_email?: boolean | null;
    }

This is causing some inefficiencies with our code. As a result of these all being optional, we have to first check if these values are defined in order to avoid TS errors.

  1. It's forcing us to make assumptions about what might and might not be optional, like so:
    const { data } = await oauth2.userinfo.get();

    if (!data.id || !data.email || !data.name) {
        // are these ever ACTUALLY going to be undefined or null? If not, this is useless logic to satisfy TS errors.
        throw new Error("Missing data from google account");
    }

    new GoogleAccount<IGoogleAccount>({
        id: data.id,
        email: data.email,
        name: data.name
    });

This could cause some unintended errors in the case that we are wrong with assuming a certain property will always be present.

  1. If we change our database schema to reflect potentially optional or null values for these properties that aren't truly optional or null, we'd then have to enforce a check anywhere we want to use them:
const googleAccount = await GoogleAccount.findOne({ id: someId });

if (googleAccount.id) {
    const someData = getSomeDataByGoogleAccountId(googleAccount.id)
}

As a result of this, I'd like to request advice on how to mitigate these issues as a result of the typescript interface definitions.

  • Are all of these properties truly optional or null? Is there ever a response in which id won't be defined within Schema$Userinfo?
  • If some of these properties are not truly optional or null, I'd like to petition there be an effort to correct the TS interface definition.

Activity

  1. added
    priority: p2Moderately-important priority. Fix may not be included in next release.
    type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.
    on Feb 1, 2023
  2. added
    type: questionRequest for information or clarification. Not an issue.
    and removed
    type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.
    on Feb 1, 2023
  3. bcoe commented on Feb 1, 2023

    @bcoe

    This library is automatically generated from the API definition here:

    https://github.com/googleapis/google-api-nodejs-client/blob/main/discovery/oauth2-v2.json

    I do not believe all fields are guaranteed to be preset for all APIs, e.g., family_name for Userinfo. However, there's no distinction in the API definition between fields that will always be present, and those that may be omitted in the response.

    Even though it's slightly annoying, I think your best bet when using these generated API surfaces is defensive programming with the response object (as you're doing).

  4. CoolTechYT commented on Feb 2, 2023

    @CoolTechYT
    Author

    @bcoe to your knowledge do you believe that at least id and email will always be present?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority: p2Moderately-important priority. Fix may not be included in next release.type: questionRequest for information or clarification. Not an issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions