From fcad4608e43ef2b8ac56330c3a0ac5fd0cfddb00 Mon Sep 17 00:00:00 2001 From: Schalli Date: Wed, 23 Sep 2026 07:39:48 +0200 Subject: [PATCH] docs(todo): Flackernder Test tenant-selector hat die Freigabe 1.3.1 blockiert 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) --- ...est-tenant-selector-zeitueberschreitung.md | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 .planning/todos/pending/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md diff --git a/.planning/todos/pending/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md b/.planning/todos/pending/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md new file mode 100644 index 0000000..76c26b5 --- /dev/null +++ b/.planning/todos/pending/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md @@ -0,0 +1,51 @@ +--- +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.