Rate limit warning

[jef]

Description

I'd like to first start off and say hello and awesome work here! I think this extension can be very useful!

I don't know all the ins-and-outs of this extension, but I'd like to talk an important topic: rate limits. It seems to me that GitLens uses an significant amount of calls to GitHub's API. So much to the point that the rate limit exceeds it's 5000 calls per hour. GraphQL calls are calculated a little more differently than regular calls.

Perhaps a disclaimer should be brought to the user saying that these limits may be quickly met if installed, as it could block work from many other applications using the endpoint.

Thanks for reading,
jef

[eamodio]

Hi, and thanks! 😄

My guess is that you are seeing a large number of calls to fetch user avatars, which are cached and stored for 7 days, until I consider then "expired" -- I probably should add a configurable setting to allow that to be bumped up or even just bump the default. Maybe even make it significantly longer, and add a command to reset the cache if needed.

Other than the avatars, GitLens queries for PRs associated with the current branch (uncached, since it can easily change), PRs associated with a commit (fetched on-demand based on line annotations/hovers, etc, but cached in memory by commit. Maybe I should store the PRs by commits too, or maybe just the set of requested commit SHAs that don't have PRs to avoid the queries. Although storing the commits SHAs not associated with a PR could in theory change when someone opens a new PR. But even as it is today, these should be a more bounded number of queries.

Are you seeing more than that?

[jef]

Thanks for great detailed response!

Are you seeing more than that?

Great question, I actually haven't looked in detail. If you could point me in the right direction of capturing all the requests through a proxy (or something similar), I don't mind posting any logs of all the calls that are going out! I wish I could give you more details, but this was only a best guess.

which are cached and stored for 7 days, until I consider then "expired" -- I probably should add a configurable setting to allow that to be bumped up or even just bump the default.

This makes sense. I don't see this being too much of a problem, but I could be wrong based on the query.

GitLens queries for PRs associated with the current branch (uncached, since it can easily change)

Mhm, mhm, makes sense!

Maybe I should store the PRs by commits too, or maybe just the set of requested commit SHAs that don't have PRs to avoid the queries.

Perhaps, not sure what could be more efficient. I suppose capturing what's getting pulled would be beneficial here so I can report back to you!

Just a thought and something to put on the back burner. If I can help by capturing any of this information, please let me know and I'll post here! Thank you.

[eamodio]

If you enable output channel logging by setting "gitlens.outputLevel": "debug" in your settings, GitLens will log to the GitLens channel in the Output pane. All the calls out to GitHub, with start with GitHubApi.

All of the queries are in https://github.com/eamodio/vscode-gitlens/blob/fd7c156584f79b00e0d8656942c353995c67a772/src/github/github.ts. Note, that getAccountForEmail isn't currently used

Thanks!

[jef]

Great, thank you. I will do it towards the end of the day when I slow down on GitHub API calls and see if I can see something irregular.