Fix #22: Seitengroesse an der Antwort messen, nicht an der Anfrage #24

2026-09-09T20:40:13Z

florian.wilde commented

2026-09-09 20:40:13 +00:00

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 für die letzte.

Die Heatmap kannte deshalb nur die jüngsten 50 Commits — und gab deren ältesten als Anfang des Zeitraums aus, ohne truncated zu setzen. Sie behauptete also Vollständigkeit, die sie nicht hatte.

Was sich ändert

Maßstab ist jetzt die erste tatsächlich gelieferte Seite. Kürzer als die heißt letzte Seite, leer heißt Ende, und der Deckel gilt weiterhin nach CALENDAR_MAX_PAGES — dann aber ehrlich mit truncated, was in der Heatmap als „(Älteres nicht abgerufen)" erscheint.

Die Lösung ist bewusst allgemein statt „dann fragen wir eben 50 an": MAX_RESPONSE_ITEMS ist konfigurierbar, eine andere Instanz kann 20 liefern.

Am echten Repository nachgesehen

florian.wilde/flimmer, das aus dem Issue — die geänderte Funktion gegen die laufende Gitea-Instanz:

vorher   Seite 1: 50                    →  50 Commits
jetzt    Seite 1: 50 | Seite 2: 26      →  76 Commits
         von=2026-09-01 bis=2026-09-09 truncated=false

Gitea selbst weist 76 aus.

Was das kostet

Bei Gitea macht der Kalender jetzt bis zu fünf Aufrufe statt einem, und ein Repository mit kurzer Historie fragt eine Seite mehr, nur um zu erfahren, dass nichts mehr kommt. Das läuft höchstens einmal am Tag — der Preis dafür, dass die Zahl stimmt, ist ihn wert. Ich schreibe es hin, statt es zu verschweigen.

An fetchRepo ändert sich nichts: dort gibt es kein Blättern, und die Aktivitätskurve kürzt sich schon heute ehrlich auf den belegten Zeitraum. Der irreführende Kommentar dazu ist richtiggestellt.

Vier bestehende Tests angefasst — mit Begründung

Ihr Fixture lieferte für jede Seite dieselben Daten und hielt nur deshalb an, weil die alte Regel eine kurze Seite für die letzte hielt — also wegen genau des Fehlers, der hier behoben wird. Kein Server verhält sich so. Sie holen ihre Daten jetzt über eineSeite() und prüfen unverändert das, worum es ihnen geht: Zählen und Filtern. Das ist keine Anpassung des Tests an den Code, sondern die Entfernung einer Abhängigkeit, die dort nie hingehörte.

Geprüft

tsc sauber · 293 Unit-Tests (4 neue) · npm run build durch
Vier neue Tests stellen eine deckelnde Gegenseite nach: 76 Commits bei Deckel 50, ein sehr kleiner Deckel, der Seitendeckel, und „die Daten sind einfach zu Ende"
Gegengeprobt: mit der alten Zeile fallen genau diese vier
Gegen die laufende Instanz gemessen, siehe oben

Die Oberfläche ist unverändert — es ändern sich nur die Zahlen dahinter. Eine Prüfung der laufenden Anwendung war nicht möglich, weil Docker Desktop hier zwischendurch stehen geblieben ist; die Datenbank hätte an dieser Änderung ohnehin nichts zu zeigen.

Closes #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 für die letzte. Die Heatmap kannte deshalb nur die jüngsten 50 Commits — und gab deren ältesten als Anfang des Zeitraums aus, ohne `truncated` zu setzen. Sie behauptete also Vollständigkeit, die sie nicht hatte. ## Was sich ändert Maßstab ist jetzt die **erste tatsächlich gelieferte Seite**. Kürzer als die heißt letzte Seite, leer heißt Ende, und der Deckel gilt weiterhin nach `CALENDAR_MAX_PAGES` — dann aber ehrlich mit `truncated`, was in der Heatmap als „(Älteres nicht abgerufen)" erscheint. Die Lösung ist bewusst allgemein statt „dann fragen wir eben 50 an": `MAX_RESPONSE_ITEMS` ist konfigurierbar, eine andere Instanz kann 20 liefern. ## Am echten Repository nachgesehen `florian.wilde/flimmer`, das aus dem Issue — die geänderte Funktion gegen die laufende Gitea-Instanz: ``` vorher Seite 1: 50 → 50 Commits jetzt Seite 1: 50 | Seite 2: 26 → 76 Commits von=2026-09-01 bis=2026-09-09 truncated=false ``` Gitea selbst weist 76 aus. ## Was das kostet Bei Gitea macht der Kalender jetzt bis zu fünf Aufrufe statt einem, und ein Repository mit kurzer Historie fragt eine Seite mehr, nur um zu erfahren, dass nichts mehr kommt. Das läuft höchstens einmal am Tag — der Preis dafür, dass die Zahl stimmt, ist ihn wert. Ich schreibe es hin, statt es zu verschweigen. An `fetchRepo` ändert sich nichts: dort gibt es kein Blättern, und die Aktivitätskurve kürzt sich schon heute ehrlich auf den belegten Zeitraum. Der irreführende Kommentar dazu ist richtiggestellt. ## Vier bestehende Tests angefasst — mit Begründung Ihr Fixture lieferte für **jede** Seite dieselben Daten und hielt nur deshalb an, weil die alte Regel eine kurze Seite für die letzte hielt — also wegen genau des Fehlers, der hier behoben wird. Kein Server verhält sich so. Sie holen ihre Daten jetzt über `eineSeite()` und prüfen unverändert das, worum es ihnen geht: Zählen und Filtern. Das ist keine Anpassung des Tests an den Code, sondern die Entfernung einer Abhängigkeit, die dort nie hingehörte. ## Geprüft - `tsc` sauber · **293 Unit-Tests** (4 neue) · `npm run build` durch - Vier neue Tests stellen eine deckelnde Gegenseite nach: 76 Commits bei Deckel 50, ein sehr kleiner Deckel, der Seitendeckel, und „die Daten sind einfach zu Ende" - **Gegengeprobt:** mit der alten Zeile fallen genau diese vier - Gegen die laufende Instanz gemessen, siehe oben Die Oberfläche ist unverändert — es ändern sich nur die Zahlen dahinter. Eine Prüfung der laufenden Anwendung war nicht möglich, weil Docker Desktop hier zwischendurch stehen geblieben ist; die Datenbank hätte an dieser Änderung ohnehin nichts zu zeigen. Closes #22

florian.wilde added 1 commit 2026-09-09 20:40:14 +00:00

fix(git): Seitengroesse an der Antwort messen, nicht an der Anfrage

CI / pruefen (pull_request) Canceled after 0s

Details

abd9f73405

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

florian.wilde referenced this pull request

2026-09-09 20:40:35 +00:00

Gitea deckelt Antworten auf 50 - die Seitenlogik rechnet mit 100 #22

florian.wilde referenced this pull request

2026-09-09 20:46:54 +00:00

Fix #23: Haengengebliebene Teil-Abrufe einmal nachschlagen #25

florian.wilde merged commit 6c788b3e7d into main

2026-09-09 22:11:45 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/nebula#24