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>
2.2 KiB
created, title, area, severity, trigger, relates_to
| created | title | area | severity | trigger | relates_to |
|---|---|---|---|---|---|
| 2026-09-23 | Flackernder Test "TenantContextSelector" — Zeitüberschreitung bei 5 s, hat die Freigabe 1.3.1 blockiert | apps/web | flake | sobald wieder an apps/web gearbeitet wird — spätestens vor der nächsten Freigabe, weil der Fall dort teuer ist. | 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
- Den Test ansehen: warum braucht er überhaupt nahe 5 s? Verdacht ist ein
waitForauf etwas, das erst nach einem Datenabruf erscheint, oder zwei Fälle (SUPER_ADMIN und ADMIN) in EINEMit, das dadurch doppelt so lange läuft — der Testname nennt beide Fälle in einem Satz. - Entweder auftrennen (zwei
it-Blöcke) oder die Wartezeit gezielt erhöhen. Ein globales Hochsetzen vontestTimeoutversteckt nur, dass hier etwas langsam ist. - 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.