Test-Suite mit 5s-Timeout flaky unter 4-shard parallel-load (P2)

Betroffene Services

• GitHub Actions CI-Pipeline
• 4 in-flight PRs

Summary

Nach dem Vitest-Sharding-Rollout (#659) wurde `eval-suite.test.ts` flaky, weil die kumulative Cold-Import-Zeit auf Shard 4/4 das 5-Sekunden-Default-Timeout überschritten hat. Vier in-flight PRs blockierten kurzzeitig, weil der gemeinsame Shard für alle vier auf demselben Test stolperte.

Root Cause

Vitest verwendet ein Per-Test-Default-Timeout von 5000 ms. Die `eval-suite.test.ts` lädt den Golden-Dataset-Runner mit 20 Aufgaben, importiert `sqlite-vec` plus den kompletten Plugin-Tree und führt anschließend die Eval gegen einen Mock-Provider aus. Lokal auf einem warmen Watch-Mode-Prozess läuft das Ganze in etwa 5 Sekunden — gerade unter dem Default. Unter dem CI-Load, in dem Shard 4/4 nach drei vorangegangenen Shards mit warmem Filesystem-Cache, aber leerem Module-Cache startet, addieren sich Cold-Imports auf 5,3-5,5 Sekunden. Das ist genug, um den Default zu reißen und einen Timeout zu werfen, der oberflächlich wie ein Assertion-Fehler aussieht.

Resolution

PR #686 hat das Per-Test-Timeout auf 30 Sekunden gebumpt — derselbe Pattern, den wir bereits mit #615 (`no-legacy-bridge.test.ts`) etabliert haben: integration-style Tests, die einen großen Import-Tree durchlaufen, definieren ihr Timeout explizit statt auf Default zu vertrauen. Wir haben die vier blockierten PRs nach dem Merge re-triggered; alle vier sind im ersten Retry grün geworden. Branch-Protection wurde währenddessen nicht umgangen — der Workaround war ausschließlich der Re-Run des fehlerhaften Shards nach Landung des Timeout-Fixes.

Preventive Actions

• Code-Style-Hinweis in `docs/decisions/test-conventions.md`: alle Integration-Tests, die den Import-Tree komplett laden, definieren ein explizites Timeout zwischen 15 und 30 Sekunden.

• CI-Load-Test im pre-merge-Check für Test-Files mit lokaler Runtime > 2 Sekunden, damit wir die Cold-vs-Warm-Differenz schon im PR sehen.

• Vitest-Setup-File pflegt eine Liste der bekannten Slow-Tests, damit künftige Sharding-Strategien diese Tests auf weniger gefüllte Shards verteilen.

Timeline