tessera-ctl/.planning/todos/completed/2026-09-23-flackernder-test-tenant-selector-zeitueberschreitung.md at main

Files

T

schalli b10734f382 test(260924-m4n): flackernden Marktplatz-Test entschaerfen, act-Warnungen der Proxmox-Kachel weg

- tenant-selector: Komponenten statisch statt im Test dynamisch importiert
  (Laden zaehlte in die 5-s-Frist des ersten Tests), SUPER_ADMIN/ADMIN in
  zwei it aufgetrennt
- marketplace/marketplace-filters: gleiche Umstellung; userEvent an die
  falsche Uhr gekoppelt statt auf shouldAdvanceTime zu warten
- proxmox-widget: Rendern wartet das erste Laden in act() ab (81 Warnungen weg)
- Todo 2026-09-23 nach completed/

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

2026-09-24 16:02:45 +02:00

3.0 KiB

Raw Permalink Blame History

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 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.
Entweder auftrennen (zwei it-Blöcke) oder die Wartezeit gezielt erhöhen. Ein globales Hochsetzen von testTimeout versteckt 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.

Erledigt in quick-260924-m4n (24.09.2026)

Ursache: TenantContextSelector und die Marktplatzseite wurden per await import(...) INNERHALB der Tests geladen. Das Laden und Umwandeln der Module zählte damit in die 5-s-Frist des ersten Tests — unter Läuferlast (drei Pipelines je Freigabe) reicht das, um die Frist zu reißen.
Behoben: statische Importe (vi.mock wird darüber gehoben), der Doppelfall SUPER_ADMIN/ADMIN in zwei it aufgetrennt (der ADMIN-Fall prüft zusätzlich, dass kein Abruf passiert). Dieselbe Umstellung in marketplace.test.tsx und marketplace-filters.test.tsx; dort ist userEvent zusätzlich an die falsche Uhr gekoppelt (advanceTimers). Kein globales testTimeout.
Messung (ganze Web-Suite, lokal und auf 2 Kerne gedrosselt): kein Test über 2 s; der langsamste lag gedrosselt bei rund 1,3 s.

3.0 KiB Raw Permalink Blame History