Cached Github token not being used for non-submission API calls, leading to rate limits

[apetresc]

Brief description of your issue

During normal use of wingetcreate.exe, I will very quickly run into the dreaded:

Octokit.RateLimitExceededException: API rate limit exceeded for 99.250.197.152. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)
   at Octokit.Connection.HandleErrors(IResponse response) in /home/runner/work/octokit.net/octokit.net/Octokit/Http/Connection.cs:line 700
   at Octokit.Connection.RunRequest(IRequest request, CancellationToken cancellationToken) in /home/runner/work/octokit.net/octokit.net/Octokit/Http/Connection.cs:line 681
   at Octokit.Connection.Run[T](IRequest request, CancellationToken cancellationToken) in /home/runner/work/octokit.net/octokit.net/Octokit/Http/Connection.cs:line 666
   at Octokit.ApiConnection.GetPage[TU](Uri uri, IDictionary`2 parameters, String accepts, ApiOptions options) in /home/runner/work/octokit.net/octokit.net/Octokit/Http/ApiConnection.cs:line 628
   at Octokit.ApiConnection.<>c__DisplayClass18_0`1.<<GetAll>b__0>d.MoveNext() in /home/runner/work/octokit.net/octokit.net/Octokit/Http/ApiConnection.cs:line 212
--- End of stack trace from previous location ---
   at Octokit.ApiPagination.GetAllPages[T](Func`1 getFirstPage, Uri uri)
   at Microsoft.WingetCreateCore.Common.GitHub.FindPackageIdRecursive(String[] packageId, String path, String exactPackageId, Int32 index)
   at Microsoft.WingetCreateCore.Common.GitHub.FindPackageId(String packageId)
   at Microsoft.WingetCreateCLI.Commands.UpdateCommand.Execute()
   at Microsoft.WingetCreateCLI.Program.Main(String[] args)
{"message":"API rate limit exceeded for 99.250.197.152. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting"}

This is just after maybe ~10-20 calls to wingetcreate.exe update [...].

The error string seems to indicate that whatever calls OctoKit is making to the GitHub API, presumably to fetch the existing manifest for it to compare the updated URLs to, are being made in a non-authenticated way. So naturally I used wingetcreate.exe token -s -t <GITHUB_API_TOKEN> to give it a token to use, expecting to increase my rate limit by a reasonable amount. Instead, nothing seems to have changed. I was still hitting the same error. This seems to indicate that the token is only used when submitting via wingetcreate.exe submit, and not other read-only calls with other commands.

Steps to reproduce

1. Set a Github access token via wingetcreate.exe token -s -t <GITHUB_API_TOKEN>
2. Use wingetcreate.exe update a dozen or so times in the same hour.
3. Encounter an unauthenticated rate limit error

Expected behavior

I would expect it to use the provided token to make authenticated calls at a higher rate limit

Actual behavior

It's still making unauthenticated calls and therefore hitting the rate limit very quickly.

Environment

PS C:\Users\apetresc\src\winget\winget-pkgs> wingetcreate.exe -?
Windows Manifest Creator v0.3.0.3

[ryfu-msft]

Hey @apetresc,

Thanks for pointing out this issue. The token associated with the token command is currently used only for login credentials, which is why it isn't helping your problem. To bypass the rate limit, try including your token with your update command.

wingetcreate update <id> -t <token>

Regardless, there should be a better help message if a rate limit is encountered.

[apetresc]

Right, I figured that the -t token is different from the login token. I guess my question is - why? These are public endpoints anyway, so it's not an elevated-permissions issue. If the login token's already there, it seems like a free way to elevate the rate limit.

I guess there is a very, very slim amount of metadata leakage happening since Github.com themselves would be better able to correlate the calls to wingetcreate update with a Github user prior to their submission, but that doesn't seem significant enough to worry about, IMO.