GitHub support deadlock: stale Contributors data cannot be resolved through any available channel #207341
🏷️ Discussion TypeBug BodyHello GitHub Community, I am documenting a support-process failure that has left a GitHub-side repository issue unresolved despite following the official guidance. Repository: After rewriting repository history and force-pushing the corrected main branch, the obsolete co-author attribution was removed successfully. The current history reachable from main is clean: no cursoragent GitHub Insights → Contributors has already recalculated correctly and shows only my account (eliv1982). The repository homepage Contributors card, however, still shows cursoragent / Cursor Agent. This means GitHub is currently showing two conflicting versions of contributor data for the same repository. The more serious issue is the support path: GitHub documentation says to wait for contributor data to refresh and contact Support if it remains incorrect. So the actual escalation path currently looks like this: Support → Community → Support → automatic closure There is no repository-owner control to refresh or invalidate the homepage Contributors cache, and rewriting the repository history again would be inappropriate because the repository history and Contributors graph are already correct. I also found a comparable Community case where the same stale Contributors issue was resolved only after a GitHub staff member manually refreshed the contributor list. At this point, the problem is not a lack of troubleshooting on the repository side. The available troubleshooting has been exhausted. The problem is that GitHub is: displaying stale contributor data on the repository homepage; That is a support deadlock. I would appreciate a clear answer to one of these two questions: What is the actual supported escalation path when contributor data remains stale after the documented refresh period and all repository-side data is already correct? I can provide screenshots showing: the homepage Contributors card still listing cursoragent; I am not asking for another generic suggestion to rewrite history, wait another 24 hours, or contact the other support channel. Those steps have already been completed. Thank you. |
Replies: 2 comments
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
The fact that Insights and the homepage disagree suggests separate cached or asynchronously refreshed data sources, not necessarily a remaining attribution in the reachable history. I would capture both views with timestamps, the repository default branch, and the latest commit SHA, then ask Support to route it as a repository metadata/indexing inconsistency. If the homepage card is generated from a cached contributor index, repeatedly rewriting history may not help and could make the evidence harder to compare; keeping the repository stable while waiting for an index refresh is safer.