schalli
fcad4608e4
Zeitueberschreitung bei 5 s auf dem Tag-Lauf, gleicher Commit auf main und live gruen. Der Abbild-Bau haengt am Test-Job, deshalb wurden Images, Release und Desktop-Pakete uebersprungen - erst der Neustart hat sie nachgeholt. Trifft jede Freigabe, weil jede drei Pipelines gleichzeitig ausloest. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
52 lines
2.2 KiB
Markdown
52 lines
2.2 KiB
Markdown
---
|
|
created: 2026-09-23
|
|
title: Flackernder Test "TenantContextSelector" — Zeitüberschreitung bei 5 s, hat die Freigabe 1.3.1 blockiert
|
|
area: apps/web
|
|
severity: flake
|
|
trigger: sobald wieder an apps/web gearbeitet wird — spätestens vor der nächsten Freigabe, weil der Fall dort teuer ist.
|
|
relates_to: Freigabe v1.3.1 (CI-Lauf 418, Job 1262)
|
|
---
|
|
|
|
## Was passiert ist
|
|
|
|
Beim Freigeben von 1.3.1 lösen drei Pipelines gleichzeitig aus (`main`, Zweig
|
|
`live`, Tag `v1.3.1`). Auf dem Tag-Lauf fiel der Test
|
|
|
|
```
|
|
src/app/(portal)/marketplace/tenant-selector.test.tsx
|
|
> TenantContextSelector > renders tenant options for SUPER_ADMIN; renders nothing for ADMIN
|
|
```
|
|
|
|
mit `Error: Test timed out in 5000ms` aus. **Derselbe Commit** (`ad004b28`) war
|
|
im selben Zeitraum auf `main` (Lauf 1025) und auf `live` (Lauf 1026) grün — es
|
|
ist also kein Fehler im Code, sondern der Läufer war mit drei parallelen
|
|
Pipelines ausgelastet und der Test lief in sein 5-Sekunden-Limit.
|
|
|
|
## Warum das teuer war
|
|
|
|
Der Abbild-Bau hängt am Test-Job. Rot heißt: **„Build & Publish Images" und
|
|
„Desktop-Pakete bauen" wurden übersprungen** — die Freigabe war damit getaggt,
|
|
aber nicht gebaut. Kein `live`-Abbild, kein Gitea-Release, keine
|
|
Desktop-Pakete. Erst ein Neustart des Laufs (Gitea-API,
|
|
`POST /actions/runs/418/rerun`) hat alles nachgeholt.
|
|
|
|
Das trifft **jede** Freigabe, weil jede Freigabe drei gleichzeitige Läufe
|
|
auslöst. Der Fall wiederholt sich also, nicht zufällig.
|
|
|
|
## Was zu tun ist
|
|
|
|
1. Den Test ansehen: warum braucht er überhaupt nahe 5 s? Verdacht ist ein
|
|
`waitFor` auf etwas, das erst nach einem Datenabruf erscheint, oder zwei
|
|
Fälle (SUPER_ADMIN und ADMIN) in EINEM `it`, das dadurch doppelt so lange
|
|
läuft — der Testname nennt beide Fälle in einem Satz.
|
|
2. Entweder auftrennen (zwei `it`-Blöcke) oder die Wartezeit gezielt erhöhen.
|
|
Ein globales Hochsetzen von `testTimeout` versteckt nur, dass hier etwas
|
|
langsam ist.
|
|
3. Prüfen, ob weitere Tests nahe am Limit liegen — die Läuferlast bleibt ja.
|
|
|
|
## Nicht die Lösung
|
|
|
|
Die drei parallelen Pipelines abschalten: der Lauf auf `main` und der auf dem
|
|
Tag prüfen unterschiedliche Dinge, und der `live`-Lauf ist die Absicherung,
|
|
dass der Zweig für sich genommen grün ist.
|