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

New Issue

2026-09-09T20:29:44Z

florian.wilde commented

2026-09-09 20:29:44 +00:00

Gitea begrenzt jede Listenantwort auf MAX_RESPONSE_ITEMS — Voreinstellung 50 —, unabhängig davon, was limit sagt. Nebula fragt an mehreren Stellen 100 an und geht davon aus, 100 zu bekommen.

Gemessen an `florian.wilde/flimmer` (76 Commits)

commits?limit=100          200    763ms    50 Eintraege
commits?limit=200          200    523ms    50 Eintraege
commits?limit=100&page=2   200    308ms    26 Eintraege     50 + 26 = 76 ✓

Was daraus folgt

calendarByPaging in lib/git/calendar.ts:88:

// Nicht mehr voll: das war die letzte Seite.
if (daten.length < CALENDAR_PAGE_SIZE) break;

CALENDAR_PAGE_SIZE ist 100, Gitea liefert nie mehr als 50 — die Schleife bricht bei jedem Gitea-Repository nach der ersten Seite ab. Die fünf erlaubten Seiten werden nie ausgenutzt.

Sichtbar bei flimmer: Heatmap „50 an 2 Tagen · seit 01.09.2026" statt der vollen Historie, Aktivitätskurve über 50 statt 100 Commits. Gitea selbst zeigt 76 Commits.

Und schlimmer als die fehlenden Daten: truncated bleibt dabei false. Die Anzeige behauptet, den ganzen Zeitraum zu kennen, den sie zeigt — dabei beginnt sie schlicht beim ältesten der 50 geholten Commits. „seit 01.09.2026" liest sich wie eine Aussage über das Repository und ist in Wahrheit eine über die Seitengröße.

Dieselbe Annahme steckt in fetchRepo, das limit=100 für die Aktivitätskurve holt und 50 bekommt.

Zu tun

Nicht die angefragte Seitengröße als Maßstab nehmen, sondern die erste tatsächlich gelieferte. Eine Seite ist erst dann die letzte, wenn sie leer ist oder kürzer als die vorherige. Der Deckel muss ehrlich gesetzt werden: reicht die Historie weiter zurück als die geholten Seiten, ist truncated wahr.

Betrifft nur Gitea — GitHub und GitLab erlauben per_page=100, dort stimmt die Annahme. Die Lösung sollte trotzdem allgemein sein: MAX_RESPONSE_ITEMS ist konfigurierbar, eine andere Instanz kann 20 oder 250 liefern.

Gitea begrenzt jede Listenantwort auf `MAX_RESPONSE_ITEMS` — Voreinstellung **50** —, unabhängig davon, was `limit` sagt. Nebula fragt an mehreren Stellen 100 an und geht davon aus, 100 zu bekommen. ## Gemessen an `florian.wilde/flimmer` (76 Commits) ``` commits?limit=100 200 763ms 50 Eintraege commits?limit=200 200 523ms 50 Eintraege commits?limit=100&page=2 200 308ms 26 Eintraege 50 + 26 = 76 ✓ ``` ## Was daraus folgt `calendarByPaging` in `lib/git/calendar.ts:88`: ```ts // Nicht mehr voll: das war die letzte Seite. if (daten.length < CALENDAR_PAGE_SIZE) break; ``` `CALENDAR_PAGE_SIZE` ist 100, Gitea liefert nie mehr als 50 — **die Schleife bricht bei jedem Gitea-Repository nach der ersten Seite ab.** Die fünf erlaubten Seiten werden nie ausgenutzt. Sichtbar bei `flimmer`: Heatmap „50 an 2 Tagen · seit 01.09.2026" statt der vollen Historie, Aktivitätskurve über 50 statt 100 Commits. Gitea selbst zeigt 76 Commits. Und schlimmer als die fehlenden Daten: `truncated` bleibt dabei **`false`**. Die Anzeige behauptet, den ganzen Zeitraum zu kennen, den sie zeigt — dabei beginnt sie schlicht beim ältesten der 50 geholten Commits. „seit 01.09.2026" liest sich wie eine Aussage über das Repository und ist in Wahrheit eine über die Seitengröße. Dieselbe Annahme steckt in `fetchRepo`, das `limit=100` für die Aktivitätskurve holt und 50 bekommt. ## Zu tun Nicht die **angefragte** Seitengröße als Maßstab nehmen, sondern die **erste tatsächlich gelieferte**. Eine Seite ist erst dann die letzte, wenn sie leer ist oder kürzer als die vorherige. Der Deckel muss ehrlich gesetzt werden: reicht die Historie weiter zurück als die geholten Seiten, ist `truncated` wahr. Betrifft nur Gitea — GitHub und GitLab erlauben `per_page=100`, dort stimmt die Annahme. Die Lösung sollte trotzdem allgemein sein: `MAX_RESPONSE_ITEMS` ist konfigurierbar, eine andere Instanz kann 20 oder 250 liefern.

florian.wilde added the in-arbeit label 2026-09-09 20:30:38 +00:00

florian.wilde started working 2026-09-09 20:30:46 +00:00

florian.wilde commented

2026-09-09 20:31:06 +00:00

🤖 Claude Code hat mit der Umsetzung begonnen.

Branch: fix/22-gitea-seitengroesse
Verstanden als: Die Seitenlogik darf nicht die angefragte Seitengröße als Maßstab nehmen, sondern muss die tatsächlich gelieferte lernen — sonst hält sie bei Gitea jede erste Seite für die letzte.
Geplantes Vorgehen:
- calendarByPaging merkt sich die Länge der ersten Seite und vergleicht daran. Kürzer als die erste heißt letzte Seite; leer heißt Ende
- truncated muss dabei ehrlich bleiben: wahr nur, wenn der Seitendeckel greift, während erkennbar noch mehr da wäre. In der Heatmap steht dann „(Älteres nicht abgerufen)"
- Nebenwirkung, die ich benenne statt sie zu verstecken: bei Gitea wird der Kalender künftig bis zu 5 Aufrufe statt einem machen — das ist der Preis dafür, dass er stimmt, und er fällt höchstens einmal am Tag an
- Der irreführende Kommentar an fetchRepo („100 statt 15") wird richtiggestellt; dort gibt es kein Blättern, die Kurve kürzt sich schon heute ehrlich auf den belegten Zeitraum
- Nachgesehen statt angenommen: gegen flimmer selbst — 76 Commits, die heute als 50 ankommen

Zeiterfassung läuft.

🤖 **Claude Code hat mit der Umsetzung begonnen.** - Branch: `fix/22-gitea-seitengroesse` - Verstanden als: Die Seitenlogik darf nicht die angefragte Seitengröße als Maßstab nehmen, sondern muss die tatsächlich gelieferte lernen — sonst hält sie bei Gitea jede erste Seite für die letzte. - Geplantes Vorgehen: - `calendarByPaging` merkt sich die Länge der **ersten** Seite und vergleicht daran. Kürzer als die erste heißt letzte Seite; leer heißt Ende - `truncated` muss dabei ehrlich bleiben: wahr nur, wenn der Seitendeckel greift, während erkennbar noch mehr da wäre. In der Heatmap steht dann „(Älteres nicht abgerufen)" - Nebenwirkung, die ich benenne statt sie zu verstecken: bei Gitea wird der Kalender künftig bis zu 5 Aufrufe statt einem machen — das ist der Preis dafür, dass er stimmt, und er fällt höchstens einmal am Tag an - Der irreführende Kommentar an `fetchRepo` („100 statt 15") wird richtiggestellt; dort gibt es kein Blättern, die Kurve kürzt sich schon heute ehrlich auf den belegten Zeitraum - Nachgesehen statt angenommen: gegen `flimmer` selbst — 76 Commits, die heute als 50 ankommen Zeiterfassung läuft.

florian.wilde worked for 8 minutes

2026-09-09 20:39:33 +00:00

florian.wilde referenced this issue from a commit

2026-09-09 20:39:48 +00:00

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

florian.wilde referenced a pull request that will close this issue

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

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

florian.wilde added zu-testen and removed in-arbeit labels 2026-09-09 20:40:21 +00:00

florian.wilde commented

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

✅ Umsetzung abgeschlossen — bereit zum Testen.

Was geändert wurde

calendarByPaging misst „volle Seite" an der ersten tatsächlich gelieferten Antwort statt an der angefragten Größe. Kürzer heißt letzte Seite, leer heißt Ende
truncated wird weiterhin nur gesetzt, wenn der Seitendeckel greift, während erkennbar mehr da wäre — in der Heatmap steht dann „(Älteres nicht abgerufen)"
Bewusst allgemein gelöst statt „dann fragen wir eben 50 an": MAX_RESPONSE_ITEMS ist konfigurierbar, eine andere Instanz kann 20 liefern
Die irreführenden Kommentare an fetchRepo in allen drei Clients richtiggestellt; dort gibt es kein Blättern und die Kurve kürzt sich schon heute ehrlich

Am echten Repository nachgesehen — flimmer, gegen die laufende Instanz:

vorher   Seite 1: 50                 →  50 Commits
jetzt    Seite 1: 50 | Seite 2: 26   →  76 Commits

Was es kostet: bei Gitea bis zu fünf Kalender-Aufrufe statt einem, und ein Repository mit kurzer Historie fragt eine Seite mehr, um zu erfahren, dass nichts mehr kommt. Läuft höchstens einmal am Tag.

Vier bestehende Tests angefasst. 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 dieses Fehlers. Sie holen ihre Daten jetzt über eineSeite() und prüfen unverändert Zählen und Filtern.

Geänderte Dateien

src/lib/git/calendar.ts · src/lib/git/calendar.test.ts
src/lib/git/gitea.ts · github.ts · gitlab.ts (nur Kommentare)

So testest du es

git switch fix/22-gitea-seitengroesse, npm run dev
Ein Gitea-Projekt öffnen, Jetzt synchronisieren
Der Kalender wird höchstens einmal am Tag geholt — zum Erzwingen in der Datenbank UPDATE "RepoSnapshot" SET "commitCalendarAt" = NULL; und erneut synchronisieren
Erwartet bei flimmer: „76 an … Tagen" statt „50 an 2 Tagen"

Geprüft: tsc sauber · 293 Unit-Tests grün (vorher 289) · npm run build durch · gegengeprobt, dass die vier neuen Tests mit der alten Zeile fallen.

Eine Prüfung der laufenden Anwendung war nicht möglich — Docker Desktop ist hier zwischendurch stehen geblieben. Die Oberfläche ist unverändert; es ändern sich nur die Zahlen dahinter.

Aufgewendete Zeit: 00:09
Pull Request: #24

Nach Freigabe: /issue-freigabe 22

✅ **Umsetzung abgeschlossen — bereit zum Testen.**  **Was geändert wurde** - `calendarByPaging` misst „volle Seite" an der **ersten tatsächlich gelieferten** Antwort statt an der angefragten Größe. Kürzer heißt letzte Seite, leer heißt Ende - `truncated` wird weiterhin nur gesetzt, wenn der Seitendeckel greift, während erkennbar mehr da wäre — in der Heatmap steht dann „(Älteres nicht abgerufen)" - Bewusst allgemein gelöst statt „dann fragen wir eben 50 an": `MAX_RESPONSE_ITEMS` ist konfigurierbar, eine andere Instanz kann 20 liefern - Die irreführenden Kommentare an `fetchRepo` in allen drei Clients richtiggestellt; dort gibt es kein Blättern und die Kurve kürzt sich schon heute ehrlich **Am echten Repository nachgesehen** — `flimmer`, gegen die laufende Instanz: ``` vorher Seite 1: 50 → 50 Commits jetzt Seite 1: 50 | Seite 2: 26 → 76 Commits ``` **Was es kostet:** bei Gitea bis zu fünf Kalender-Aufrufe statt einem, und ein Repository mit kurzer Historie fragt eine Seite mehr, um zu erfahren, dass nichts mehr kommt. Läuft höchstens einmal am Tag. **Vier bestehende Tests angefasst.** 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 dieses Fehlers. Sie holen ihre Daten jetzt über `eineSeite()` und prüfen unverändert Zählen und Filtern. **Geänderte Dateien** - `src/lib/git/calendar.ts` · `src/lib/git/calendar.test.ts` - `src/lib/git/gitea.ts` · `github.ts` · `gitlab.ts` *(nur Kommentare)* **So testest du es** 1. `git switch fix/22-gitea-seitengroesse`, `npm run dev` 2. Ein Gitea-Projekt öffnen, **Jetzt synchronisieren** 3. Der Kalender wird höchstens einmal am Tag geholt — zum Erzwingen in der Datenbank `UPDATE "RepoSnapshot" SET "commitCalendarAt" = NULL;` und erneut synchronisieren 4. Erwartet bei `flimmer`: „**76** an … Tagen" statt „50 an 2 Tagen" **Geprüft:** `tsc` sauber · 293 Unit-Tests grün (vorher 289) · `npm run build` durch · gegengeprobt, dass die vier neuen Tests mit der alten Zeile fallen. Eine Prüfung der laufenden Anwendung war nicht möglich — Docker Desktop ist hier zwischendurch stehen geblieben. Die Oberfläche ist unverändert; es ändern sich nur die Zahlen dahinter. **Aufgewendete Zeit:** 00:09 **Pull Request:** #24 Nach Freigabe: `/issue-freigabe 22`

florian.wilde referenced this issue

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

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

florian.wilde closed this issue

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

florian.wilde referenced this issue from a commit

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

Merge #22: Seitengroesse an der Antwort messen

florian.wilde removed the zu-testen label 2026-09-09 22:12:44 +00:00

florian.wilde referenced this issue from a commit

2026-09-09 22:16:32 +00:00

chore(release): v1.11.0