Worth noting first: flutter/flutter is a genuinely enormous monorepo — it absorbed the whole engine repo into its history a while back, so it has one of the largest commit histories on GitHub. That matters here because the contributors graph isn't computed live; it's a cached statistics job, and GitHub's own stats API documents that recomputation can take noticeably longer than the usual ~24h window on repos this size, sometimes returning a 202 while it's still working through the backlog.

That's the most likely explanation over "stale/broken data" specifically: GET /repos/flutter/flutter/stats/contributors — if you hit that endpoint directly and it returns 202 Accepted instead of 200 with data, that means GitHub is still (re)computing the stats cache, and querying it is actually what nudges a recompute along. Worth trying that before assuming something's actually broken, since everything else you've verified (default branch, author resolution, verified email, not a merge commit, not hitting the top-100 limit) checks out clean.

One more detail from looking at the commit itself: it shows 3 authors (you plus two co-authors via Co-authored-by trailers). If the graph is still catching up on a repo this size, it's possible the co-author attribution specifically lags behind the primary-author attribution even after the primary sync catches up — worth checking if you show up once the graph does update, even before the co-authors do.

If it's still missing after giving the stats endpoint a chance to recompute (could be a while for a repo this size, not just a few minutes):

• This isn't something a GitHub Free support ticket can escalate for a repository-level data issue like this — repo-owned data problems on someone else's repo generally go through GitHub Community Discussions (which you're already using) rather than personal Support, since Support mainly handles account-level issues.
• The more direct route for something specific to flutter/flutter itself is filing an issue in the repo (flutter/flutter/issues) tagged appropriately, since the Flutter team/GitHub infra folks who'd actually look at a stats-graph anomaly on their own repo are more likely to see it there than in the general community forum.

Given you've already ruled out every documented user-side cause, I'd bet this resolves itself once the stats cache catches up on a repo this large — but if it's still missing in a week or two, that's the point where it's worth an actual issue rather than assuming it'll fix itself indefinitely.

Hi @krystic,

Given the extensive troubleshooting you have already completed, you have successfully eliminated all standard user-error scenarios outlined in GitHub's official contribution guidelines.

Since your commit (e4c0224) is a non-merge commit (parent_count: 1), accurately resolves to your handle via the API, and sits directly on the default branch of flutter/flutter, your configuration is flawless. This issue is almost certainly a backend indexing stall or a cached data rendering failure on GitHub’s analytics worker queue. Large repositories with massive commit histories (like Flutter) occasionally experience these synchronization delays on the backend.

Final Check Before Escalating

Since the commit was merged on 2026-08-05 and it has been a week, this is definitely past the standard 24-hour cache window. Verify one last detail:

• Commit Date vs. Author Date: The patch notes show an author date of Aug 6 (+0800). Ensure you are filtering the repository contributors graph by "Commits" and expanding your date picker to cover a broad window (e.g., Aug 1 to Aug 10, 2026) to account for any timezone conversion offsets used by GitHub's backend metrics engine.

How to Report This as a GitHub Free User

As a Free tier user, you cannot open a standard technical support ticket, but you can force GitHub to review platform analytics bugs through these channels:

1. Trigger the GitHub Support Virtual Assistant: Navigate to the GitHub Support Contact Page. Start a chat with the automated assistant and use exact technical phrases like "Recalculate Contributions" or "Repository Graph Re-index". The bot is programmed to recognize these platform-level glitches and will often automatically queue your account/repository for an asynchronous backend refresh, or route you to an escalation form.
2. Escalate via Your Existing Community Thread: GitHub Community managers regularly audit active posts. Adding a concise technical summary to your thread makes it easy for them to flag your case internally to the engineering team.

Recommended Reply Template for Your Discussion Thread

Copy and paste this update into your active discussion post to summarize your findings for the GitHub staff:

Update: I have re-verified that all platform requirements are fully met. 
- Commit e4c0224 is on the default master branch.
- Parent count is 1 (not a merge commit).
- The patch email is verified and set as my primary account email.
- The GitHub API explicitly resolves the author to my handle (@krystic).

Since the commit was merged on 2026-08-05, this is not a standard 24-hour refresh delay. It appears to be an indexing stall or a stale cache bug on the backend analytics engine for the flutter/flutter repository. 

Could a GitHub community manager or staff member please request a manual contribution recalculation/re-index for my profile against this repository? Thank you!