`contributor_aliases` table empty or not populating recent entries

[MoralCode]

This is separate from the issue with the contributors table. This seems like it may be related to github events API changes relating to contributor information

[sgoggins]

This is related to the recent changes in the GitHub Events API, and we need to address those changes.

[ANJAN672]

Investigation Findings

I did a deep dive into the codebase to understand how contributor_aliases gets populated. Here's what I found:

Code Flow

facade_phase() → insert_facade_contributors() → process_commit_metadata()
  → get_login_with_commit_hash() OR get_login_with_supplemental_data()
    → insert_alias() → contributor_aliases table

Potential Root Causes Found

1. Silent Failure when GitHub returns author: null

File: augur/tasks/github/facade_github/contributor_interfaceable/contributor_interface.py (lines 389-392)

try:
    match = login_json['author']['login']
except:
    match = None

When a commit author's email isn't linked to a GitHub account, the Commit API returns {"author": null}. The bare except: silently catches the TypeError and returns None - no alias is created and no warning is logged.

This is likely a significant contributor to missing data, especially for external contributors whose emails aren't linked to GitHub accounts.

2. Emails become permanently "unresolved"

File: augur/tasks/github/facade_github/tasks.py (lines 38-43)

Once an email fails resolution (for ANY reason - including temporary API failures or rate limiting), it's inserted into unresolved_commit_emails and never retried. This means temporary failures become permanent data loss.

3. GitHub Search API rate limiting

The fallback fetch_username_from_email() uses /search/users which has stricter rate limits (30 req/min). When rate-limited, emails become permanently "unresolved" per issue #2 above.

Recommended Fixes

1. Replace bare except: with specific handling - Check if author is None before accessing login, and log when this happens
2. Add retry mechanism for unresolved emails - Allow re-trying failed emails after a time period
3. Add explicit logging when author: null to track occurrence frequency

---

Happy to help implement fixes if the team agrees on the approach!

[shlokgilda]

@ANJAN672 this is a solid analysis, thanks for digging into this. I verified all three issues you identified:

1. Bare except: - Yeah, when GitHub returns {"author": null} (commits where the email isn't linked to an account), the code catches the TypeError silently and just returns None. No logging.

2. Permanent skip - Once an email hits unresolved_commit_emails, it's skipped forever with just a debug log. The table was probably intended as a "don't waste API calls on known-bad emails" optimization, but it became a data loss mechanism.

3. Rate limit - The except Exception catches everything including RatelimitException, converts it to None, and then the calling code treats that as "email not found" and inserts into unresolved. So a temporary rate limit becomes a permanent failure.

The tricky part is we probably need to differentiate between different kinds of GitHub API failures:

Permanent failures (shouldn't retry):

• 404 Not Found (email genuinely doesn't exist on GitHub)
• Deleted/ghost users
• Invalid email formats

Transient failures (should retry):

• Rate limits (403/429)
• Network timeouts
• Temporary API errors

Right now everything gets lumped together as "unresolved."

[ANJAN672]

@MoralCode and @sgoggins let me know once we can work on this!!! Coz for now its tagged for more info so

[MoralCode]

This seems to be a blog post about the events api changes sean was talking about: https://github.blog/changelog/2025-08-08-upcoming-changes-to-github-events-api-payloads/

I dont think the events part of the API matters here (have yet to find where in the code we are processing events specifically). While the blog post does mention:

Author association fields: The author_association field will be removed from multiple event types (Pull Request, Pull Request Review, Pull Request Review Comment, Issue, Issue Comment, Commit Comment, and Discussion) to improve response times.

This doesnt seem to affect the Commit API that we seem to be querying in this particular chain

[MoralCode]

permalink to line: https://github.com/chaoss/augur/blob/7122c730769d53e3f2d6d810eee0a3eca896c247/augur/tasks/github/facade_github/contributor_interfaceable/contributor_interface.py#L389

It seems like this issue is comprised of several different/independent bugs, and that solving any one of them likely wont do much.

1. I like the idea of changing the above mentioned code to have its final layer of access (['login']) use a .get() so it can automatically return None, skipping the try catch. Also we could possibly lump this into the above if statement, also gaining us reuse of the error message
2. we need to fix the bug where unresolved emails are not being reconsidered. More digging should be done to see whether this ever used to work, or if this feature/optimization was ever finished. Consulting the ye wise council of elder:tm: maintainers would be probably necessary here

To contrast with everyone else, I really dont see evidence for this being related to exceptions from githubs API. If we got back no data, or an error code, the author field itself wouldnt exist, possibly triggering the earlier if statement, not the later try catch block.

Also, likely due to lack of time, I haven't yet fully traced through to see where this code inserts into (or doesn't insert into) contributor_aliases. I think I'm struggling to see the connection between "some github api entries have no author value" and "nothing is making it to contributor_aliases". is every value from github returning this way?

fixing the first item so we can use that log statement (or a slightly different one thats unique to this) is I think going to be a helpful step towards tracing the broader roots of this issue. I dont see why we cant open a narrowly focused PR for that fix as part of gathering info on this PR (just maybe wait until we have fewer than 30 open PRs... being at almost 70 is uuh... pretty unsustainable)

[MoralCode]

we need to fix the bug where unresolved emails are not being reconsidered.

#3711 purports to solve this, although i dont agree with the specific approach

---

for this issue as a whole i think #3694 and #3740 and #3739 are all likely related/causes of this, and i think together, their PRs present an effective fix for this.

TL:DR, empty string author names in commit processing caused several problems, including skipping add of all new contributors because one empty name and a name based lookup got into the unresolved emails table.

I believe the code that will be shipped in v0.93 fixes contributor resolution going forward, meaning this issue is solved and pending release