Builds failing - REST API returning 202 and never 200. about github-stats

[CodyNotFound]

As far as I know, these APIs all return 202:

• Get the weekly commit activity
• Get the last year of commit activity
• Get all contributor commit activity
• Get the weekly commit count
• Get the hourly commit count for each day

[stevenjwheeler]

Haha, you wouldn't believe the number of times I've done that trying to figure this out 😂

[stevenjwheeler]

[stevenjwheeler]

Please see pull request #46 as I believe that I might have fixed this error.

[CodyNotFound]

I resolved the 202 error that kept reporting according to your Pull Request #46.

But there is still a little problem here:
In the file overview.svg.
The value of Lines of code changed is always 0.

Can you fix the problem?
Thank you.

[CodyNotFound]

This line of code may use an invalid API

It returned to

{

}

I think that's why it's always 0.

[stevenjwheeler]

Ah yeah, I see the problem. Seems there's also a problem with the stars as I definitely do not have 8k stars 😂
Turning on exclude_fork_repos also did not fix this, so the API is returning some weird results.

[stevenjwheeler]

Okay, it seems that when /repos/{repo}/stats/contributors is ran through the queries.query_rest method with my fix of /user/, the API returns a 404 for not found, but without the /user/ it returns 202 for processing.

That means my fix just bypasses the part where it gets lines of code changed, essentially, by causing all repos to 404.

The problem is that the API never returns a 200 after sending a 202, so could this be an issue on GitHub's side, and not actually the code?
I've searched all over the documentation for the API and the code does appear correct according to the documentation including authentication.

Stats that use the GraphQL API instead work fine as far as I know.

[theCalcaholic]

Even though the API paths aren't correct in github-stats, the correct paths don't work either. That definitely looks like an API bug. Not even the example from the documentation works:

$ curl -i  -H "Accept: application/vnd.github.v3+json"   https://api.github.com/repos/octocat/hello-world/stats/contributors
HTTP/2 202 
server: GitHub.com
date: Sun, 22 Aug 2021 18:30:55 GMT
content-type: application/json; charset=utf-8
content-length: 5
x-github-media-type: github.v3; format=json
access-control-expose-headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, Deprecation, Sunset
access-control-allow-origin: *
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'
vary: Accept-Encoding, Accept, X-Requested-With
x-ratelimit-limit: 60
x-ratelimit-remaining: 57
x-ratelimit-reset: 1629660598
x-ratelimit-resource: core
x-ratelimit-used: 3
x-github-request-id: BB1E:12FC:550C0B:61B2A6:612297DF

{

}

I have reported the bug to GH

[stevenjwheeler]

Thank you for reporting the bug @theCalcaholic, however, I have checked the API paths in github-stats today and they do seem to match the documentation. ({repo} is populated like /{user}/{reponame}, so github-stats is passing the correct API path.)

It does definitely seem like a GitHub bug.

[theCalcaholic]

Ah, you're right!

Turns out I broke the path myself and fixed it again later :D

[CodyNotFound]

Github Docs
It seems that the API in the repos/{owner}/{repo}/stats directory have been broken
They only returned an empty json like

{

}

[stevenjwheeler]

Okay, after undoing my "fix that wasn't a fix", it seems that GitHub has now fixed this issue as my image has now generated correctly, so I shall close the issue.
Feel free to reopen it if it's still not working for you.

Thanks guys!

[jstrieb]

I've been quietly following this thread, but haven't had time to chime in. Glad it's resolved, at least for the moment!

I'll be sure to link back to this if others are having similar problems.