florian.wilde
abd9f73405
CI / pruefen (pull_request) Canceled after 0s
Behebt florian.wilde/nebula#22. Gitea deckelt jede Listenantwort auf MAX_RESPONSE_ITEMS (Voreinstellung 50), egal was limit sagt. calendarByPaging verglich gegen die angefragten 100 und hielt damit bei jedem Gitea-Repository die erste Seite fuer die letzte. Die Heatmap kannte nur die juengsten 50 Commits - und gab deren aeltesten als Anfang des Zeitraums aus, ohne truncated zu setzen. Sie behauptete also Vollstaendigkeit, die sie nicht hatte. Maßstab ist jetzt die erste tatsaechlich gelieferte Seite. Kuerzer als die heisst letzte Seite, leer heisst Ende, und der Deckel gilt weiterhin nach CALENDAR_MAX_PAGES - dann aber ehrlich mit truncated. Am echten Repository nachgesehen, dem aus dem Issue: vorher Seite 1: 50 -> 50 Commits jetzt Seite 1: 50 | Seite 2: 26 -> 76 Commits Gitea selbst weist 76 aus. WAS DAS KOSTET Bei Gitea macht der Kalender jetzt bis zu fuenf Aufrufe statt einem, und ein Repository mit kurzer Historie fragt eine Seite mehr, um zu erfahren, dass nichts mehr kommt. Das laeuft hoechstens einmal am Tag; der Preis dafuer, dass die Zahl stimmt, ist ihn wert. VIER BESTEHENDE TESTS ANGEFASST Ihr Fixture lieferte fuer jede Seite dieselben Daten und hielt nur deshalb an, weil die alte Regel eine kurze Seite fuer die letzte hielt - also wegen genau des Fehlers, der hier behoben wird. Kein Server verhaelt sich so. Sie holen ihre Daten jetzt ueber eineSeite() und pruefen unveraendert das, worum es ihnen geht: Zaehlen und Filtern. Vier neue Tests stellen eine deckelnde Gegenseite nach. Gegengeprobt: mit der alten Zeile fallen genau diese vier. Refs #22