[BUG]: Users[].GetAsync() does not return correct data

[martincostello]

What happened?

Using the GitHubClient.Users[].GetAsync() returns a value with a null value for the PublicUser and PrivateUser properties.

The generated code to call /users/{login} appears to not be expecting the correct payload:

public static WithUsernameGetResponse CreateFromDiscriminatorValue(IParseNode parseNode)
{
    if (parseNode == null)
    {
        throw new ArgumentNullException("parseNode");
    }

    string value = parseNode.GetChildNode("")?.GetStringValue();
    WithUsernameGetResponse withUsernameGetResponse = new WithUsernameGetResponse();
    if ("private-user".Equals(value, StringComparison.OrdinalIgnoreCase))
    {
        withUsernameGetResponse.PrivateUser = new PrivateUser();
    }
    else if ("public-user".Equals(value, StringComparison.OrdinalIgnoreCase))
    {
        withUsernameGetResponse.PublicUser = new PublicUser();
    }

    return withUsernameGetResponse;
}

I would expect it to just return the user as-is:

{
  "login": "martincostello",
  "id": 1439341,
  "node_id": "MDQ6VXNlcjE0MzkzNDE=",
  "avatar_url": "https://avatars.githubusercontent.com/u/1439341?v=4",
  "gravatar_id": "",
  "url": "https://api.github.com/users/martincostello",
  "html_url": "https://github.com/martincostello",
  "followers_url": "https://api.github.com/users/martincostello/followers",
  "following_url": "https://api.github.com/users/martincostello/following{/other_user}",
  "gists_url": "https://api.github.com/users/martincostello/gists{/gist_id}",
  "starred_url": "https://api.github.com/users/martincostello/starred{/owner}{/repo}",
  "subscriptions_url": "https://api.github.com/users/martincostello/subscriptions",
  "organizations_url": "https://api.github.com/users/martincostello/orgs",
  "repos_url": "https://api.github.com/users/martincostello/repos",
  "events_url": "https://api.github.com/users/martincostello/events{/privacy}",
  "received_events_url": "https://api.github.com/users/martincostello/received_events",
  "type": "User",
  "site_admin": false,
  "name": "Martin Costello",
  "company": "@justeattakeaway",
  "blog": "https://martincostello.com",
  "location": "London, UK",
  "email": null,
  "hireable": null,
  "bio": ".NET developer, tester and Microsoft MVP based in London working for Just Eat Takeaway.com",
  "twitter_username": "martin_costello",
  "public_repos": 163,
  "public_gists": 13,
  "followers": 504,
  "following": 20,
  "created_at": "2012-02-15T09:43:20Z",
  "updated_at": "2024-06-08T18:05:14Z"
}

Versions

0.0.16

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[github-actions[bot]]

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

[kfcampbell]

Ooh, interesting find. I've confirmed this, and when you remove the if ("private-user".Equals(value, StringComparison.OrdinalIgnoreCase)) logic, the response gets populated exactly as you'd expect.

I'm going to file an issue with Kiota for this.

[kfcampbell]

Reported upstream at https://github.com/microsoft/kiota/issues/4844!

[martincostello]

The upstream issue seems to have been closed due to a lack of activity. Looks like they say the OpenAPI schema is wrong as it doesn't have a discriminator?

[kfcampbell]

Yep, they're correct. We need to update the schema internally; our team just hasn't had the time yet. We'll keep this open and return to it when we can!

[martincostello]

Kiota v1.20.0 was released yesterday, and that looks like it contains the bug fix you needed to be able to resolve this?

[eashwar]

Wanted to chime in and mention I see the same behavior with the API call to get the currently authenticated user of the client (i.e. client.User.GetAsync(). It'd be great to know when we can expect this category of bug to be fixed. This project is super promising and we're excited to explore it! Thanks.