---
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.

## 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.