API requests

[real-yfprojects]

The github action outputs some metrics about the run. The metrics for API requests often come near to or even reach the upper cap. However next to the metric it says 200+ required. Why does it use 5000 requests then? Is the cap of 5000 imposed by github? And is it possible that the profile data is incorrect because the cap was reached?

I have activated the indepth mode.

[spenserblack]

Is the cap of 5000 imposed by github?

Yes: https://api.github.com/rate_limit
Note that the capacity from this endpoint may be lower if you don't use a token when requesting from it.

[spenserblack]

I believe it is an issue with GitHub. The only thing I can think of is, if metrics receives an empty object, to provide a warning that some data was missing from the API. Or to automatically retry the endpoint.

It's odd because just now I queried the endpoint, got an empty object again, queried immediately after, and got data. It makes me think that there's some race condition where the data sometimes isn't fully populated before it's returned, but I honestly don't know the cause.

[lowlighter]

The github action outputs some metrics about the run. The metrics for API requests often come near to or even reach the upper cap. However next to the metric it says 200+ required. Why does it use 5000 requests then? Is the cap of 5000 imposed by github?

Actually, the section you're reffering to is your current quota (remaining / max possible request), not what the action will consume.
5000/5000 means that you have all your "API credit".

As @spenserblack mentionned, the upper limit is set by GitHub and as far as I know it's not possible to increase it.

API requests (REST)                                             │ 5000/5000 (200+ required)
API requests (GraphQL)                                          │ 5000/5000 (200+ required)
API requests (Search)                                           │ 30/30

The "requirement" in parenthesis is set by quota_required_rest and quota_required_graphql which are values that you can change to prevent the action from running if your current quota is lower than specified (can be used to avoid the action resulting in errors). So by default, the action won't run if you have less than 200 API requests possible in either category.

The actual number of requests consumed by the action is displayed a bit further down in the log (https://github.com/real-yfprojects/real-yfprojects/actions/runs/3374159000/jobs/5599488074#step:2:3368):

Consumed API requests                                           │  
  * provided that no other app used your quota during execution │ 
REST API                                                        │ 20
GraphQL API                                                     │ 53
Search API                                                      │ 0

This just checks you quota after the run and shows the difference with the quota before, it doesn't actually compute manually each request performed, which is why it could be innacurate if you use your quota with other apps hence the note

And is it possible that the profile data is incorrect because the cap was reached?

If the cap was reached, most probably what would happens is that plugins will start to display "An unexpected error occured" than displaying stuff as the octokits (GitHub API sdk) will start throwing errors

So the displayed number should still be what it would have been either way, but some sections will just not render at all

However, this is interesting: right now it seems like the repos/OWNER/REPO/stats/contributors API endpoint, which is used to get contribution stats, is returning unexpected results. For example:

$ gh api repos/lowlighter/metrics/stats/contributors
{}

@lowlighter Are you also seeing this? Could it be a permissions issue?

I don't remember where this endpoint is exactly used, but if it's the one used by line plugin yeah I noticed it (I think they were some discussion about it too but can't find it back)

What I assume is happening is that this endpoint has some "cache" system where calling it will trigger the refresh/computation. I'm not sure but I think I remember the output may also change between calls, so maybe the stats is being populated in parallel.
But as you said it may just be a race condition. Either way it's definitely an issue on GitHub's side.

I guess it'd be possible to retry the endpoint to mitigate this, as a contributor should have non-zero stats, and unless empty a repository also should have at least one contributor.

---

Hope it makes it a bit clearer 😄

[spenserblack]

I don't remember where this endpoint is exactly used, but if it's the one used by line plugin yeah I noticed it (I think they were some discussion about it too but can't find it back)

Oh yeah it's not used directly in this repo AFAIK (but referenced when mocking), but from octokit (getContributorStats), which uses that endpoint.

[real-yfprojects]

Thanks @lowlighter. That did make it clear. The line plugin shows incorrect data again (and now I know, it is not because the action ran out of API requests).

[real-yfprojects]

The line plugin shows incorrect data again

This is still an issue. It seems like github will need some time (<20min) to calculate the correct data that is fetched from the API.
I was thinking that maybe I could include a call to the relevant API in my github action, wait some time and then run metrics.