waka-readme-stats: BUG : Action Fails

Describe the bug image image

Actions get failed from a month…

image

Traceback (most recent call last):
  File "/waka-readme-stats/main.py", line 221, in <module>
    run(main())
  File "/usr/local/lib/python3.11/asyncio/runners.py", line 190, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/asyncio/base_events.py", line 653, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/waka-readme-stats/main.py", line 208, in main
    stats = await get_stats()
            ^^^^^^^^^^^^^^^^^
  File "/waka-readme-stats/main.py", line 156, in get_stats
    yearly_data, commit_data = await calculate_commit_data(repositories)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/waka-readme-stats/yearly_commit_calculator.py", line [37](https://github.com/ddok2/ddok2/actions/runs/4403414537/jobs/7711737364#step:3:38), in calculate_commit_data
    await update_data_with_commit_stats(repo, yearly_data, date_data)
  File "/waka-readme-stats/yearly_commit_calculator.py", line 65, in update_data_with_commit_stats
    date = search(r"\d+-\d+-\d+", commit["committedDate"]).group()
                                  ~~~~~~^^^^^^^^^^^^^^^^^
TypeError: 'NoneType' object is not subscriptable
sys:1: RuntimeWarning: coroutine 'AsyncClient.get' was never awaited

Github repository link

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 11
  • Comments: 38 (1 by maintainers)

Commits related to this issue

Most upvoted comments

@ddok2, could you please inspect, how does it happen that committedDate is None? According to GitHub documentation, it’s a required field. If it becomes None sometimes, we can use the None check you propose, and I would suggest writing to GitHub support about the issue. Because in general in my opinion we would rather rely on documentation then doublecheck everything.

@willnaoosmith, there’s no such option yet, but we are always open to ideas and/or proposals!

I think the problem is that once the repository has enough commits, it takes too long for GitHub to process the data, so it returns an 503 error. Re-doing the repository, cleaning the commit history might do it. Mine has 2.720 commits as now. @mikebronner has 1K. So it might be a new limitation on the GitHub API, or something like this. If anyone tries to fix it by doing my suggestion, let us know!

I think we fhould file an issue to GitHub support, shouldn’t we?

Yup both would be good. Once I got some time, I’m going to try what I suppose might work, just to get some intel on the cause of the problem and help a little!

@pseusys, I agree with your comment. I’ll inspect the issue again. If this is a problem with Gtihub, I will open an issue with Github support and close this issue.

@doctormin I used all flag your settings, and it worked. Thank you

In my case, time-out errors happened when fetching the commit history of a large repo of mine So this bug can be temporarily avoided by turning:

SHOW_COMMIT flag to "False" in your GitHub Action YML file

You guys can give it a try: example