Investigate Kiota non-determinism

[kfcampbell]

Related to #15 and #27.

For some reason, in the file generated/go/users/item_starred_repository.go, Kiota occasionally generates a file that includes

// ItemStarredRepositoryable
type ItemStarredRepositoryable interface {
    IAdditionalDataHolder
}

when it otherwise generates (correctly)

// ItemStarredRepositoryable
type ItemStarredRepositoryable interface {
    i878a80d2330e89d26896388a3f487eef27b0a0e6c010c493bf80be1452208f91.AdditionalDataHolder
    i878a80d2330e89d26896388a3f487eef27b0a0e6c010c493bf80be1452208f91.Parsable
}

We should take this to the Kiota team and see if they can point us in the right direction.

[baywet]

Most likely related to this microsoft/kiota#3339
Can you provide the OpenAPI description for the type?
Do you know how often it's referenced?
Which version of kiota are you using at the moment?

Can you try to set the KIOTA_GENERATION_MAXDEGREEOFPARALLELISM environment variable to 0 before you run kiota and see if you get better results? (expect significant performance reduction)

[kfcampbell]

Can you provide the OpenAPI description for the type?

Our schema makes this pretty difficult with its large size unfortunately. My best guess is it's:

a "simple-user" (in a dropdown to condense the comment)

"simple-user": { "title": "Simple User", "description": "A GitHub user.", "type": "object", "properties": { "name": { "nullable": true, "type": "string" }, "email": { "nullable": true, "type": "string" }, "login": { "type": "string", "example": "octocat" }, "id": { "type": "integer", "example": 1 }, "node_id": { "type": "string", "example": "MDQ6VXNlcjE=" }, "avatar_url": { "type": "string", "format": "uri", "example": "https://github.com/images/error/octocat_happy.gif" }, "gravatar_id": { "type": "string", "example": "41d064eb2195891e12d0413f63227ea7", "nullable": true }, "url": { "type": "string", "format": "uri", "example": "https://api.github.com/users/octocat" }, "html_url": { "type": "string", "format": "uri", "example": "https://github.com/octocat" }, "followers_url": { "type": "string", "format": "uri", "example": "https://api.github.com/users/octocat/followers" }, "following_url": { "type": "string", "example": "https://api.github.com/users/octocat/following{/other_user}" }, "gists_url": { "type": "string", "example": "https://api.github.com/users/octocat/gists{/gist_id}" }, "starred_url": { "type": "string", "example": "https://api.github.com/users/octocat/starred{/owner}{/repo}" }, "subscriptions_url": { "type": "string", "format": "uri", "example": "https://api.github.com/users/octocat/subscriptions" }, "organizations_url": { "type": "string", "format": "uri", "example": "https://api.github.com/users/octocat/orgs" }, "repos_url": { "type": "string", "format": "uri", "example": "https://api.github.com/users/octocat/repos" }, "events_url": { "type": "string", "example": "https://api.github.com/users/octocat/events{/privacy}" }, "received_events_url": { "type": "string", "format": "uri", "example": "https://api.github.com/users/octocat/received_events" }, "type": { "type": "string", "example": "User" }, "site_admin": { "type": "boolean" }, "starred_at": { "type": "string", "example": "\"2020-07-09T00:17:55Z\"" } }, "required": [ "avatar_url", "events_url", "followers_url", "following_url", "gists_url", "gravatar_id", "html_url", "id", "node_id", "login", "organizations_url", "received_events_url", "repos_url", "site_admin", "starred_url", "subscriptions_url", "type", "url" ] },

Though it's difficult for me to see how the starred items line up with the property of starred_url.

Do you know how often it's referenced?

Between nullable-user and simple-user, there are 183 references in our schema.

Which version of kiota are you using at the moment?

 sh$ kiota --version
1.8.1+c93d90721f5ff6e0af6c2f41babbf5f2e7bbae61

Can you try to set the KIOTA_GENERATION_MAXDEGREEOFPARALLELISM environment variable to 0 before you run kiota and see if you get better results? (expect significant performance reduction)

I removed the hack to fix this and ran generation five times each with the env variable set and without it set. The error occurred on 3/5 runs without the environment variable but only 1/5 runs with the environment variable. Interestingly, the performance degradation was not noticeable; perhaps we should be conducting all of our runs like that?

[baywet]

Before you lock your generation workflow to a single thread, I'd like us to look into fixing the underlying issue since you experience it even on a single thread. Can you create an issue in kiota for this one please?

[kfcampbell]

Done! See microsoft/kiota#3700.