You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Secondary: collect_pull_request_review_comments getting stuck on repos with no pull requests/comments #200
I am unsure if this is its own bug or something thats showing up because of other things:
I am noticing that secondary tasks (collect_pull_request_review_comments) are running for a suspicious amount of time when there is no pull requests / no pull request comments and I am not seeing them complete.
Migrated comment from original
Originally posted by @shlokgilda on 2026-02-09
Dug into this. There are a few things going on that together explain why secondary collection gets stuck on repos with no
PRs/comments. Mainly that we don't have task level timeouts for the individual tasks in the Celerey group() in https://github.com/chaoss/augur/blob/main/augur/tasks/start_tasks.py#L122-L127 .
Now I think this was an intentional design choice. But please correct me if I am mistaken.
Any comments returned would fail the mapping lookup and get skipped anyway — the API call is completely wasted. Compare with collect_pull_request_reviews which already has an early return at https://github.com/chaoss/augur/blob/main/augur/tasks/github/pull_requests/tasks.py#L483-L485 when there are no PRs. collect_pull_request_review_comments should do the same when there are no reviews.
collectoss-issue-migrator commented on Apr 30, 2026
Migrated comment from original
Originally posted by @shlokgilda on 2026-02-09
A likely bigger problem in my opinion is that process_ossf_dependency_metrics can hang indefinitely. The scorecard subprocess call in https://github.com/chaoss/augur/blob/main/augur/tasks/util/worker_util.py#L132 uses timeout=None. The scorecard binary makes its own network calls to GitHub. If it hangs (network issues, rate limits, whatever), the Celery
worker hangs forever.
Since process_ossf_dependency_metrics is in the same group() as the PR review comment task, maybe the entire group never completes and secondary_task_success_util never runs. This is probably why these repos appear stuck? It might not actually be collect_pull_request_review_comments that's blocking, but the scorecard subprocess. Can we check the logs to see this for those blocking repos?
collectoss-issue-migrator commented on Apr 30, 2026
Migrated comment from original
Originally posted by @MoralCode on 2026-02-10
Made a new issue for the scorecard stuff #202, but given that cali was noticing scorecard issues as well (and has been for a while) maybe that could be related?
collectoss-issue-migrator commented on Apr 30, 2026
Migrated comment from original
Originally posted by @shlokgilda on 2026-02-12
Since @cdolfi confirmed the analysis, I guess just adding an early return when pr_review_id_mapping is empty, same pattern that collect_pull_request_reviews already uses.
collectoss-issue-migrator commented on Apr 30, 2026
Migrated comment from original
Originally posted by @shlokgilda on 2026-02-12
That said, I don't think the missing early return is what's actually causing these repos to appear stuck. For repos with no PRs, the GitHub API call to /repos/{owner}/{repo}/pulls/comments would just return an empty array and the task would finish quickly.
So the early return fix is still worth doing (saves a wasted API call and key allocation per empty repo), but it probably won't fix
the "stuck" behavior on its own.
collectoss-issue-migrator commented on Apr 30, 2026
Migrated comment from original
Originally posted by @MoralCode on 2026-02-12
i mean we could clone those repos locally and run scorecard on them, but I don't know if that would be a proper test since you wouldn't be testing in the same "the keys get used up pretty quickly" environment that i suspect our instance is creating
collectoss-issue-migrator commented on Apr 30, 2026
Migrated comment from original
Originally posted by @shlokgilda on 2026-02-13
Fair point on the environment. Can we check the production logs (if we have those?) for those repos to see which task is actually blocking? That'd confirm whether it's scorecard or something else. Either way, I'll open a PR for the early return fix since that's confirmed.
collectoss-issue-migrator commented on Apr 30, 2026
Migrated comment from original
Originally posted by @MoralCode on 2026-02-16
reopening for cali to verify this fix in the next release since this was marked as "partially fixes" in the associated PR, inadvertently triggering github to link them
Activity
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@shlokgildaon 2026-02-09Dug into this. There are a few things going on that together explain why secondary collection gets stuck on repos with no
PRs/comments. Mainly that we don't have task level timeouts for the individual tasks in the Celerey
group()in https://github.com/chaoss/augur/blob/main/augur/tasks/start_tasks.py#L122-L127 .Now I think this was an intentional design choice. But please correct me if I am mistaken.
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@shlokgildaon 2026-02-09At https://github.com/chaoss/augur/blob/main/augur/tasks/github/pull_requests/tasks.py#L244-L247, the task builds a
pr_review_id_mappingfrom the DB. For repos with no PRs, this mapping is empty. But instead of returning early, the task still proceeds to create aGithubRandomKeyAuth,spin up aKeyClient, and make a GitHub API call at https://github.com/chaoss/augur/blob/main/augur/tasks/github/pull_requests/tasks.py#L263.Any comments returned would fail the mapping lookup and get skipped anyway — the API call is completely wasted. Compare with
collect_pull_request_reviewswhich already has an early return at https://github.com/chaoss/augur/blob/main/augur/tasks/github/pull_requests/tasks.py#L483-L485 when there are no PRs.collect_pull_request_review_commentsshould do the same when there are no reviews.collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@shlokgildaon 2026-02-09A likely bigger problem in my opinion is that
process_ossf_dependency_metricscan hang indefinitely. The scorecard subprocess call in https://github.com/chaoss/augur/blob/main/augur/tasks/util/worker_util.py#L132 usestimeout=None. The scorecard binary makes its own network calls to GitHub. If it hangs (network issues, rate limits, whatever), the Celeryworker hangs forever.
Since
process_ossf_dependency_metricsis in the samegroup()as the PR review comment task, maybe the entire group never completes andsecondary_task_success_utilnever runs. This is probably why these repos appear stuck? It might not actually becollect_pull_request_review_commentsthat's blocking, but thescorecardsubprocess. Can we check the logs to see this for those blocking repos?collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@MoralCodeon 2026-02-10Made a new issue for the scorecard stuff #202, but given that cali was noticing scorecard issues as well (and has been for a while) maybe that could be related?
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@cdolfion 2026-02-10@shlokgilda I do think you have identified the problem/solution for the collect_pull_request_review_comments issue
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@shlokgildaon 2026-02-12Since @cdolfi confirmed the analysis, I guess just adding an early return when
pr_review_id_mappingis empty, same pattern thatcollect_pull_request_reviewsalready uses.collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@shlokgildaon 2026-02-12That said, I don't think the missing early return is what's actually causing these repos to appear stuck. For repos with no PRs, the GitHub API call to
/repos/{owner}/{repo}/pulls/commentswould just return an empty array and the task would finish quickly.So the early return fix is still worth doing (saves a wasted API call and key allocation per empty repo), but it probably won't fix
the "stuck" behavior on its own.
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@shlokgildaon 2026-02-12For the listed repos, can we run scorecard directly? If we see that scorecard is not the blocker, we probably should look elsewhere.
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@MoralCodeon 2026-02-12i mean we could clone those repos locally and run scorecard on them, but I don't know if that would be a proper test since you wouldn't be testing in the same "the keys get used up pretty quickly" environment that i suspect our instance is creating
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@shlokgildaon 2026-02-13Fair point on the environment. Can we check the production logs (if we have those?) for those repos to see which task is actually blocking? That'd confirm whether it's scorecard or something else. Either way, I'll open a PR for the early return fix since that's confirmed.
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@MoralCodeon 2026-02-13wonder if related to #183 as well
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@cdolfion 2026-02-13@MoralCode I dont think they are related
collectoss-issue-migrator commentedon Apr 30, 2026
Note
Migrated comment from original
Originally posted by
@MoralCodeon 2026-02-16reopening for cali to verify this fix in the next release since this was marked as "partially fixes" in the associated PR, inadvertently triggering github to link them
MoralCode commentedon Nov 5, 2026
hmmm not sure if this is quite the same issue as is being fixed in #393 .