Der oxfmt-Test bekommt eine eigene, begründete Zeitgrenze - #281
Merged
Merged
Conversation
…All (#275) 'prints what oxfmt would print, for an edit of every kind' spawns oxfmt once per case, 21 spawns in a row. Measured 2026-09-24: 2.3s on an otherwise idle machine, 14.4s against 18 busy loops on a 20-core box, timing out against Vitest's 5s default testTimeout under exactly that kind of load, which is what #275 hit against a parallel npm run check. The spawning moves into a beforeAll that states its own explicit timeout, 30s, twice the loaded measurement rather than a guess. The it() itself now only asserts the precomputed pairs, which is why it was possible to give it none of that headroom: the assertions were never what was slow. testTimeout stays at its default everywhere else. Closes #275
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Worum es geht
apps/workbench/test/preview/home-document.test.tsscheiterte manchmal an Vitests 5-Sekunden-Grenze, obwohl nichts kaputt war, nämlich wenn der Rechner gerade stark ausgelastet war. Am 24.09.2026 hat das einmal das Hochladen von Code blockiert.Was sich ändert
Gemessen statt geraten: Ein einzelner Test, „prints what oxfmt would print, for an edit of every kind“, startet für jeden seiner 21 Testfälle den Formatierer
oxfmtals eigenen Prozess, nacheinander. Auf einem ruhigen Rechner dauert das 2,3 Sekunden. Unter einer Last von 18 Dauerschleifen auf einer Maschine mit 20 Kernen dauerte derselbe Test 14,4 Sekunden, deutlich über den 5 Sekunden, die Vitest einem einzelnen Test standardmäßig gibt, und genau die Art von Last, unter der #275 auch tatsächlich auftrat.Das Starten der 21 Prozesse zieht jetzt in ein
beforeAllum, das seine eigene, im Code begründete Zeitgrenze von 30 Sekunden bekommt, das Doppelte der gemessenen, belasteten Zeit. Der eigentliche Test prüft danach nur noch die vorbereiteten Ergebnisse und ist damit selbst in unter einer Millisekunde fertig. Die globale Zeitgrenze bleibt unverändert.Vorher/nachher, derselbe Testlauf unter derselben Last (18 Dauerschleifen, 20 Kerne):
Technische Details
Die Vermutung im Issue war ein langsamer erster Import; gemessen war die Ursache stattdessen
execFileSyncfür denoxfmt-Binary, 21-mal hintereinander in einemit(). EinbeforeAllmit explizitem, im Kommentar begründetem drittem Argument (30_000) übernimmt das Spawnen und fülltoxfmtCases: { printed, formatted }[]; derit()-Block iteriert nur noch darüber. Kein anderer Test in der Datei ändert sich, undtestTimeoutbleibt überall auf seinem Standardwert.Gemessen mit 18
while true; do :; done-Hintergrundprozessen (timeout 40s) auf einer Maschine mit 20 Kernen, mitnpx vitest run test/preview/home-document.test.ts --reporter=verbose, vor und nach der Änderung, jeweils ausapps/workbenchheraus.npm run checklief einmal vollständig grün.Closes #275
🤖 Generated with Claude Code