Unreliable /commits endpoint

[infinisil]

The /commits endpoint we're using right now sometimes doesn't return any entries, causing accidental retirement PRs to be opened (#97, #98, #99).

nixpkgs-committers/scripts/retire.sh

Lines 112 to 116 in 6076321

	trace gh api -X GET /repos/"$ORG"/"$ACTIVITY_REPO"/commits \
	-f since="$(date --date='1 year ago' --iso-8601=seconds)" \
	-f author="$login" \
	-f committer=web-flow \
	-f per_page=100 \

[mdaniels5757]

Also #95. :)

[emilazy]

This is because the endpoint has an internal timeout and will silently “succeed” with an empty result instead of returning an error when it reaches the timeout. This also shows up in the web UI where sometimes it’ll look like people with commits don’t have any. I guess GitHub’s backend has just gotten slower and so this is happening now. The issue with timeout feedback was reported to GitHub along with other issues with the endpoint but unfortunately they didn’t act on it. We could re‐raise just that issue but I’m not optimistic there’d be any change.

I suspect that lowering -f per_page=100 may help mitigate this, because it means the endpoint can “stop searching quicker” for users with less than 100 commits in the past year, but I don’t think it’d make it wholly reliable.

I have a local half‐done rewrite of the retirement flow that runs much more quickly and also fixes the issue with lf- by avoiding relying on any of the problematic endpoints; I could try to prioritize finishing that up, especially if this happens again.

[infinisil]

I'm manually turning off the retire workflow because of this for now

[infinisil]

We shouldn't let this be disabled for too long, so I'll enable it again. Let's hope the issues are addressed on GitHub's side