Réduire l'attente de la suite de tests sans retirer un seul test ni un seul OS #293

Contribution state

Backlog · priority Low · No release assigned.

Topics: Tooling, LATER. Maintainer contact: Guillaume Fossier. Created: 2026-09-22T20:19:07.132Z.

Backlog. Propose a scope or supply missing evidence here; the maintainer confirms prerequisites and sequencing before implementation.

This issue contains the requirements, acceptance criteria, decisions and evidence needed for a contribution. Discuss scope and ownership here, and link this issue from your pull request. This is a snapshot synchronized on 2026-10-05, source last updated 2026-10-02T01:46:12.156Z.

Public roadmap

Dependencies and scope links

Parent: #289 — Ramener le verdict requis d'une PR Semctx au coût réel de ce qu'il prouve

Related context:

• #291 — Exécuter le benchmark multicœur à côté de verify:pr plutôt qu'après — Backlog
• #290 — Ramener le benchmark multicœur à quelques minutes sans retirer d'échantillon ni d'empreinte — Backlog

Requirements, decisions and evidence

Dated statements below retain their original scope and dates. Historical CI, release, NOW and local experiments do not override the current contribution state above. LOCAL_EVIDENCE and LOCAL_ARTIFACT identify unpublished maintainer artifacts; their presence is not public reproducibility proof. Private corpus identifiers have been removed while measurements and unknowns are retained.

Décision de tranche — 2 octobre 2026

La piste de scheduler PR hoklims/semctx#178 reste non intégrée. Le protocole préenregistré de GitHub #205 a conclu NO_GO : série 47 tests/0 échec/94,426 s ; parallèle ×2 interrompu au pic working set arbre 1 614 475 264 octets, au-delà du plafond 1 610 612 736. Les quatre phases restantes ne sont pas exécutées ; aucune médiane ni gain valide. Issue GitHub #205 close NOT_PLANNED, prototype conservé à 262861cb6fb94c1df05d1cc0c70472bbe3297bfb. Cette issue de résultat reste au backlog, sans prétendre que toute parallélisation est impossible. Reprise uniquement sur nouveau levier mémoire/isolation ou budget explicitement révisé avant mesure. #205 (comment).

Résultat attendu

La même suite canonique (bun test --timeout 60000 packages apps plugins scripts, package.json:45) rend son verdict nettement plus tôt, d'abord sous Windows. Rien n'est retiré : mêmes 180 fichiers, mêmes 2 583 tests, mêmes assertions, sur les 3 OS. Chaque run prouve qu'aucun fichier ni aucun test n'a été oublié.

La gate locale, obligatoire avant chaque mise à jour de PR, en profite aussi : elle prend aujourd'hui 1 207 s sous Windows. Cible proposée : suite Windows en 10 min au plus en CI.

Pistes proposées :

• exécution parallèle par fichier avec Bun 1.4.0 (--parallel, --timings), ou répartition en lots entre jobs (--shard) ;
• une seconde passe séquentielle pour les fichiers sensibles au temps ;
• un découpage de scripts/continuity-demo.test.ts, qui fixe le plancher ;
• une correction du nettoyage de plugin-status-attestation.

Constat mesuré

• Durées sur le run main 35112922445 : Windows 1 429,85 s, Ubuntu 538,87 s, macOS 526,71 s. La somme des durées par fichier égale le total : l'exécution est strictement séquentielle. La suite représente 95 % du verify:pr Windows.
• Options disponibles mais inutilisées : Bun 1.4.0 est épinglé (ci.yml:36) et bun test --help liste --parallel, --shard, --timings et --update-timings. Aucune n'est utilisée.
• Pas de test coupable unique :
  • aucun test ne dépasse 24,7 s ;
  • les 10 fichiers les plus lents font 52 à 55 % du temps ;
  • les 80 fichiers qui lancent des processus font 96 % du temps Windows ;
  • Windows multiplie le coût par 2,65 au total, et par 16 à 19 sur les fichiers dominés par git.
• continuity-demo est le fichier n°1 sur les 3 OS : 193,8 s sous Windows, 108,7 s sous Ubuntu, 89,4 s sous macOS. 23 de ses 28 tests rejouent le parcours complet (environ 17 commandes) pour injecter une seule mutation.
• plugin-status-attestation perd environ 10 s par run sous Linux et macOS après son dernier test (écart mesuré sur deux runs). Mécanisme inféré : le afterAll fait 20 tentatives à 500 ms sur un répertoire resté en 0o500 (plugin-status-attestation.test.ts:173-178, 496-508).
• Tests sensibles au temps : attestation flood et délai (l.239-251, 740-754), impact-pilot (l.1724-1731), index-lifecycle-concurrency (l.125, 214).
• Plancher calculé (répartition LPT, sans contention) : 357 s sous Windows et 135 s sous Ubuntu avec 4 processus.

Valide lorsque

• Avant/après sur le même commit, sur les 3 OS, avec au moins 3 runs de chaque côté : on publie la durée de la suite et de verify:pr par OS, en médiane et en étendue. Le nombre de processus est choisi sur mesure, pas sur le plancher calculé.
• Complétude assertée à chaque run : l'union des fichiers exécutés égale l'inventaire des fichiers de test, et les nombres de tests réussis et ignorés égalent ceux de l'exécution séquentielle. Un témoin négatif (un fichier retiré d'un lot) est observé rouge.
• Aucune nouvelle instabilité : 5 runs répétés verts par OS (valeur proposée), fichiers sensibles au temps compris, ou ces fichiers exécutés hors parallélisme.
• Aucun test ni aucune assertion retiré ou affaibli : le diff se limite à l'organisation et au nettoyage. La revue proof-integrity indépendante rend ALLOW, y compris sur verify-pr.test.ts:76-87, qui fige la commande canonique.

Limites de la validation

• Inconnus : le nombre de vCPU des runners et la stabilité de --parallel sous Windows en Bun 1.4.0.
• Le fichier de timings sert seulement à équilibrer les lots. Il ne doit jamais décider qu'un test est ignoré.
• Tant que le benchmark domine, ce gain ne raccourcit pas le verdict requis.
• Le partage de fixtures entre tests d'app-services est hors de cette issue, à cause du risque sur l'identité de dépôt (freshness.ts:229-236).

Dated source discussion

These notes preserve decisions and evidence at their original dates. Current planning status is stated above; historical NOW, pending CI and release claims remain historical.

2026-09-23

Instabilité POSIX de --parallel : cause trouvée (bug Bun), parallèle limité à Windows

Constat en CI (#178, commit 89120ad, 3 premiers runs) : la passe parallèle échoue une fois sous macOS (4 tests) et une fois sous Ubuntu (5 tests), jamais sous Windows. Chaque échec est un test qui atteint son propre budget (15, 30 ou 60 s), suivi par Bun qui tue un enfant « dangling ». En séquentiel sur macOS, ces mêmes tests prennent 0,1 à 5,9 s.

Reproduit sous WSL Ubuntu (Bun 1.4.0, 12 cœurs) :

• Suite complète à 4 workers, interrompue avant la fin : 40 délais dépassés et 73 enfants « dangling ».
• apps et packages/mcp-server avec --parallel=4 : bug touché dans 2 runs sur 5. Dans l'un, 3 tests atteignent leur budget ; l'autre bloque plus de 25 min. Les 2 autres échecs viennent de l'environnement WSL (npm Windows sans node).
• Les mêmes fichiers avec --isolate, sans --parallel : 441/441 verts.
• Reproductions minimales, toutes vertes en parallèle : spawnSync(["true"]), cycles git, enfants bun.

État capturé pendant un blocage :

• le git lancé par spawnSync est zombie (terminé, jamais récupéré) ;
• le worker n'a plus aucun pipe ouvert ;
• son thread principal tourne en boucle à 100 % d'un cœur.

C'est oven-sh/bun#34069 : ouverte, reproduite en 1.4.0 et 1.4.2 ; correctif proposé dans oven-sh/bun#40078, avec des changements demandés. Pendant un spawnSync, le GC libère un poll sur la mauvaise boucle d'événements ; le compteur dérive, et un spawnSync ultérieur tourne sans source de réveil. Les runs séquentiels y sont exposés aussi, mais beaucoup plus rarement ; les workers parallèles multiplient l'exposition.

Décision appliquée (commit à venir sur #178), conforme au résultat attendu de l'issue, qui vise « d'abord sous Windows » :

• Windows garde les deux passes (parallèle à 4 workers, puis 5 fichiers seuls).
• Linux et macOS repassent à une seule passe séquentielle : la commande canonique, plus un rapport JUnit.
• Le contrôle de complétude couvre les deux plans.
• Windows étant le chemin critique du verdict requis, le gain est conservé.

Réactivation : quand un Bun corrigé est épinglé et que 5 runs CI par OS sont verts avec le parallèle.

Preuves locales du candidat : Windows, verify:pr EXIT=0, 181/181 fichiers, 2 599 tests, 7 skip, 0 fail, suite en 469 s (300 s en parallèle, 169 s en séquentiel). Le chemin Linux est en cours de validation sous WSL.

2026-09-23

Stabilité CI de 6f15963 (parallèle sous Windows seulement) : 5 runs

Chaque run rapporte ses 181/181 fichiers avec 2 599 tests. Sous POSIX, la passe séquentielle unique ne touche plus le bug Bun.

Échec Windows (tentative 5) : le run est dégradé dans son ensemble. Quatre tests y prennent entre 27 et 59 s, alors qu'ils prennent de 0,1 à 17 s sur les 4 autres runs.

• Seul « packs and installs a portable CLI » franchit son budget : npm install --offline tourne encore à 60 s, Bun le tue, puis le afterAll échoue en EBUSY.
• Ce test prend 11 à 20 s seul sur le runner Windows, et 23 à 30 s à côté de 3 workers.

Correctif (candidat suivant, verify:pr local EXIT=0, 175 fichiers en parallèle et 6 en séquentiel, 0 fail, suite en 428 s) : apps/cli/test/package-runtime.test.ts rejoint la passe séquentielle.

Risque résiduel, nommé :

• dans le run dégradé, un test continuity-demo a atteint 59,4 s de son budget de 60 s (12,7 à 16,1 s dans les autres runs) ;
• la parité d'octets de Control Handoff v2 monte à 20,6 s sur 30 s dans les runs normaux.

Passer continuity-demo en séquentiel coûterait environ 190 s sous Windows. 5 nouveaux runs mesureront ce risque.

Resources

• test: run the canonical suite in parallel and prove every file ran

Contribute through GitHub

Contributing · First check · Public contracts · Support

Discuss design questions, blockers and ownership in this issue. Link it from the PR; include the applicable evidence required by the current repository contributor contract. A merged PR does not automatically prove publication, runtime activation or every acceptance criterion.