Stale Contributors cache: 25+ unanswered threads over 3 years — repo owners need a self-service refresh, not silence

[k0b3n4irb]

🏷️ Discussion Type

Product Feedback

Body

This is a meta-report. It is not one more "my sidebar is stale" thread — it is
a census of all of them, because the pattern is now impossible to miss.

The problem, in one paragraph

After a history rewrite (force-push), the repository homepage's Contributors
sidebar keeps showing contributors that no longer exist in any commit.
Every data source GitHub itself exposes agrees the contributor is gone —
GET /repos/{repo}/contributors, GET /repos/{repo}/stats/contributors,
commit search, the Insights graph — yet the homepage sidebar disagrees, for
months, with no way for the owner to force a recalculation. In 2026 this
got much worse: thousands of repos are rewriting history to remove
Co-authored-by trailers added by AI tools, and every one of them hits this
wall.

The census: 25+ threads, 3+ years, zero staff responses

I went through this community with the API. Here is every thread I found on
this exact subject. I also checked the authorAssociation of every
commenter on the ten most active threads: not a single STAFF reply
anywhere — only users answering users with "wait 24 hours" (it doesn't) or
"block the account" (a workaround that should embarrass the product).

"claude" stale-contributor wave (the AI-trailer cleanup era):

Thread	Opened	Status
#188915	2026-03-08	unanswered
#189812	2026-03-16	unanswered
#191565	2026-04-04	unanswered
#193962	2026-04-25	unanswered
#194652	2026-05-03	unanswered
#197389	2026-05-30	unanswered
#202123	2026-07-16	unanswered
#202538	2026-07-21	unanswered — explicitly titled "second confirmed report"
#203349	2026-07-29	"answered" by a user repeating wait ~24h
#203482	2026-07-30	unanswered

General stale-contributors-after-rewrite:

Thread	Opened	Status
#49813	2023-03-11	42 upvotes, unanswered after 3 years
#113236	2024-03-19	unanswered
#140791	2024-10-07	unanswered
#194601	2026-05-02	unanswered
#200957	2026-07-04	unanswered — API-vs-sidebar divergence fully documented
#201246	2026-07-08	unanswered
#201982 / #202032	2026-07-15/16	unanswered
#202055	2026-07-16	unanswered
#202205	2026-07-17	unanswered
#202450	2026-07-20	unanswered
#202539 / #202540	2026-07-21	unanswered
#202610	2026-07-22	"answered" = a moderator moving it to another category
#202619	2026-07-22	unanswered
#203504	2026-07-30	unanswered
#203718	2026-08-02	unanswered

Fifteen of these threads were opened in the last five weeks. The oldest
has been waiting since March 2023. The two threads marked "answered"
contain, respectively, a category move and advice that demonstrably does not
work. That is the entire official engagement with this problem, ever.

Why this matters more than a cosmetic sidebar

1. GitHub's own surfaces contradict each other. The API says one
   contributor; the homepage says three. Whichever is right, one of them is
   serving wrong data indefinitely.
2. Attribution is not cosmetic. The sidebar credits accounts — bots,
   AI tools, ex-contributors — with authorship of a codebase they have no
   commits in. For a maintainer, that is a misrepresentation on the most
   visible page of their project.
3. The rewrite was done exactly as documented. GitHub's own docs on
   removing sensitive data say: rewrite, force-push, contact Support for
   cached data. The first two are self-service; the third is a black box
   with no queue, no status, no SLA — for an operation that is almost
   certainly one cache invalidation.

Concrete proposals (pick any one — each would empty this census)

1. Self-service recalculation. A "Recompute contributors" action for
   repo owners — a button in Insights or
   POST /repos/{owner}/{repo}/contributors/rebuild. Precedent exists:
   Pages rebuilds, server-side git gc, cache-purge endpoints. Rate-limit
   it to once a day per repo if abuse is a concern.
2. A real queue for cache/purge requests. If it must stay manual, give
   us a tracked request type: I file "refresh contributors on repo X" /
   "drop orphaned refs/pull/N", it enters a queue, I see a status. It is
   2026; "open a support ticket and hope" is not a workflow.
3. At minimum: expire the cache. If the sidebar cache had any TTL
   consistent with the "wait for the refresh" advice, none of these threads
   would exist. Months is not a TTL, it is a leak.

And a related self-service gap in the same workflow: after a rewrite, the old
commits stay reachable forever through hidden refs/pull/*/head refs that
owners cannot delete (deny updating a hidden ref). The same queue — or the
same button — should cover purging those for the repo you own.

The part that should worry GitHub

Everyone in these 25 threads did the right thing: they searched, found prior
threads, added their data, and waited. The platform's answer, across three
years, has been literally nothing. People notice — several of these threads
already end with "moving to GitLab". I would rather this get fixed than
migrate a 12-crate project, which is why I took an evening to write the
census instead of the migration script.

If a staff member reads one contributors thread this year, make it this one —
all the others are linked above.

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.