GitHub ersetzt stargazer-Scraping durch eine privacy-safe history-API
GitHub gab an, eine auf Stargazer basierende Workaround durch einen speziell entwickelten History-Endpunkt ersetzt zu haben, der aggregierte Sterntrends zurückgibt, ohne einzelne Identitäten offenzulegen. Die Änderung ist wichtig, weil Wartungsmitarbeiter den Sternenverlauf nutzen, um einzuschätzen, ob eine Veröffentlichung, ein Start oder ein Ereignis die Entwicklung eines Projekts verändert hat, während GitHub sagte, der ältere Ansatz werde für die Datenerhebung missbraucht und sei zudem teuer in der Bedienung.
Was GitHub verändert hat
In einem Beitrag vom 14. Oktober 2026 Ingenieur sagte GitHub, dass die neue Repository Star History API bis zu 30 Wochen tägliche Sternenzählungen in einer einzigen Anfrage zurückgeben kann, ohne dass Identitäten zugeordnet sind. GitHub sagte, der Endpunkt filtert Sterne nach der Zeit, bevor sie zählen, anstatt zuerst zu zählen und die Antwort später zu kürzen, was die Datenbankarbeit verringert.
Das Unternehmen erklärte, dass der vorherige GET /repos/{owner}/{repo}/stargazers-Endpunkt so konzipiert wurde, dass er aktuelle Stargazer auflistet und nicht als historisches Ereignisprotokoll dient. Da Sterne entfernt werden, wenn Nutzer ein Repository entstaren, bewahrt das Modell keine vollständige Geschichte vergangener Starring- und Unstarring-Aktivitäten. GitHub sagte, dass Tools Seiten mit Stargazer-Datensätzen gelesen und die Benutzernamen verworfen haben, um eine Kurve allein anhand von Zeitstempeln zu rekonstruieren.
Warum der alte Ansatz zum Problem wurde
GitHub sagte, der ursprüngliche Endpunkt habe zwei Probleme verursacht. Erstens standen Identitäten für Massensammlungen zur Verfügung, was laut Ansicht Böswichte dazu veranlasste, öffentliche Stargazer-Listen für Spam- und Phishing-Kampagnen zu durchsuchen. Zweitens könnten hoch versehene Repositories die Datenbank dazu zwingen, viele tausend Einträge zu verarbeiten, um eine einzelne Seite zurückzugeben.
Für react/react, das laut GitHub etwa 251,000 Sterne hatte, dauerte die Rekonstruktion der vollständigen Kurve etwa 2,511 Anfragen nach dem alten Ansatz. GitHub sagte außerdem, dass ein Paginierungsfehler bedeutete, dass jede Anfrage alle Sterne zählte, um die Seitenanzahl zu bestimmen, selbst wenn nur bis zu 100 Personen zurückgegeben wurden. In der Woche vor der Einschränkung des Zugriffs gab GitHub an, dass fast 37,000 langsame Zähl-Anfragen protokolliert wurden, durchschnittlich fast 3 Sekunden, und Datenbank-Safeguard-Maßnahmen haben mehr als 1,000 davon beseitigt. Nachdem der Zugriff eingeschränkt wurde, sagte GitHub, dass die Stargazer-Anfragen um etwa 60% gesunken sind und die Gesamtzeit für die Zählabfrage um etwa 80% gesunken ist.
Wie der neue Endpunkt funktioniert
GitHub sagte, es habe mehrere Designs bewertet, bevor es sich für einen Zeitbereichsansatz entschieden hat. Eine Option hätte Stargazer-Zeitstempel ohne Identitäten zurückgegeben, aber GitHub sagte, dass API-Konsumenten weiterhin durch große Mengen einzelner Datensätze blättern müssten. Eine andere Option hätte zuerst Sterne aggregiert und später paginiert, aber GitHub sagte, ein Standard-SQL-Plan würde weiterhin alle passenden Zeilen scannen und gruppieren, bevor LIMIT und OFFSET angewendet werden.
Das ausgelieferte Design mappt stattdessen Seite und per_page auf einen indexierten created_at Bereich, filtert zuerst Sterne auf diesen Bereich und gruppiert dann die Ergebnisse in tägliche Zählungen. GitHub sagte, das bedeutet, dass eins Anfrage bis zu 30 Wochen Geschichte abdecken kann, und eine zunehmende Seite rückwärts durch den Verlauf eines Repositoriums bewegt. Im React/React-Beispiel sagte GitHub, dass der neue Ansatz etwa 24 Anfragen statt etwa 2,511 verlangt, während jeder Stern etwa einmal über den gesamten Verlauf untersucht wird.
Grenzen und verbleibende Kompromisse
GitHub sagte, der neue Endpunkt sei sicherer und vorhersehbarer, aber nicht frei von Einschränkungen. Kalendergrenzen beeinflussen, wie der Verlauf aufgeteilt wird, entfernte Sterne werden im Modell nicht erhalten, und ungewöhnlich dichte Wochen können weiterhin langsame oder teure Abfragen erzeugen. GitHub sagte außerdem, dass dichte Wochen weiterhin eine Skalierungsbeschränkung sind, obwohl der normale Anfragepfad nicht mehr jeden aktuellen Stern abfragt.
Das Unternehmen erklärte, dass die Überprüfung des Sternengeschichtsproblems auch zu einer separaten Korrektur bei GitHub.com geführt habe, bei der die Repository-Stargazer-Seite aktualisiert wurde, um zwischengespeicherte Sternenzählungen zu verwenden, anstatt Sterne auf Abruf zu zählen. GitHub sagte, diese Änderung habe jede Woche Hunderte langsamer Anfragen von dieser Seite entfernt.