`Include_all_commits` sometimes shows incorrect number of commits

[nxwi]

Describe the bug

On GitHub Stats the number of commits is currently showing the last years commits, after adding include_all_commits it decreases as shown below.

Expected behaviour

Shows the number of commits in 2022

Screenshots / Live demo link (paste the github-readme-stats link as markdown image)

Before adding include_all_commits After adding include_all_commits

[rickstaa]

@nasw1j, I checked the codebase, and I think both count_private and include_all_commits parameters are correctly implemented.

https://github.com/anuraghazra/github-readme-stats/blob/9a909ff0a41a6abba34b008ce57744d7cb2cd220/src/fetchers/stats-fetcher.js#L155-L163

I, therefore, think the error is caused by incorrect data returned from GitHub's REST API and GraphQL API APIs. If this happens, these wrong values are cached for 4 hours.

https://github.com/anuraghazra/github-readme-stats/blob/9a909ff0a41a6abba34b008ce57744d7cb2cd220/api/index.js#L60-L64

When this happens, you can check the console.log to see if there is any error and use the &v=123 syntax to force the cache to reload.

Detailed explanation

If include_all_commits is enabled, and GitHub REST API fails the code will return 0.

https://github.com/anuraghazra/github-readme-stats/blob/9a909ff0a41a6abba34b008ce57744d7cb2cd220/src/fetchers/stats-fetcher.js#L69-L100

This will then be used as the total commits. To this value, the private commits will be correctly added if count_private is enabled. Since we used caching, this wrong value will be on the card for 4 hours.

Posible solutions

We can use the previous cache when this problem happens.

[rickstaa]

I quickly checked #1691 created by @Rongronggg9 and think merging to his pull request will significantly improve the commit accuracy. I, however, did not have time to do a thorough review 😅.

Nevertheless, still, one problem persists with #1691 merged. It will show a commit count of 0 when the GitHub Rest API fails. @Rongronggg9 maybe, if the Rest API fails, we can use the old cache or prevent the wrong result from being cached?

https://github.com/anuraghazra/github-readme-stats/blob/9a909ff0a41a6abba34b008ce57744d7cb2cd220/api/index.js#L66

Maybe this can be achieved by changing the cache header when the Rest API fails (see https://vercel.com/docs/concepts/edge-network/caching).

[Rongronggg9]

I see. I will find some time to take a look at it.

[rickstaa]

@Rongronggg9 No pressure your PR looks very promising, take your time! 🚀

[rickstaa]

@Rongronggg9 See #2177 and 4df8094e5266f28f7367552980f4e00b0c9421a9 for a example on how to purge the cache when the GraphQL and Rest api fail.

Further, please read https://github.com/anuraghazra/github-readme-stats/pull/211 because we are currently not fetching commits by year. In short, this is because we are trying to prevent the GraphQL and Vercel timeout limits from reaching. I think we could add this more accurate commit fetching, but it should be disabled by default to prevent any rate limits from being hit on the Public Vercel instance. I"m doing something similar on #2159.

[rickstaa]

I created https://github.com/community/community/discussions/35675 to ask GitHub to make the totalCommitContributions and restrictedContributionsCount objects available under the user object. This feature would allow us to solve #1515 for the Public Vercel instance. Please show your support at https://github.com/community/community/discussions/35675.

[rickstaa]

For future reference, a (draft) PR to improve this behaviour can be found at https://github.com/anuraghazra/github-readme-stats/pull/2448.

[rickstaa]

As pointed out by @Madhav-MKNC in https://github.com/anuraghazra/github-readme-stats/issues/2851#issue-1762042673, for some accounts the total commit count is lower than the yearly commit count. This is also caused by the use of the GitHub Search API, which is known to be buggy.

https://github.com/anuraghazra/github-readme-stats/blob/eebaa44f2ad1d63373ca04d4d0be54c3e6eba5e0/src/fetchers/stats-fetcher.js#L149

If you want this fixed please add your support to https://github.com/orgs/community/discussions/35675 so we can fix this in the future 🙏🏻. Furthermore, this behaviour will be improved when the GitHub action is released with https://github.com/anuraghazra/github-readme-stats/pull/1691 merged under an environmental variable.

[rickstaa]

The behavoir should be improved when

• [ ] https://github.com/anuraghazra/github-readme-stats/pull/3238
• [ ] https://github.com/anuraghazra/github-readme-stats/pull/2448

are merged.

[rickstaa]

Should be fixed now that #2448 and #3238 are merged.