ci: Scripts Tests (CPU) -- un worker xdist mort bloque la jambe jusqu'au plafond (14-17 min de silence apres [99%])

[jsboige]

Le defaut

Sur Scripts Tests (CPU), les annulations au plafond ne sont pas des runs lents coupes par le mur. Les quatre cas cites comme « depassements francs » par la PR #16087 sont des runs bloques : leur travail est termine depuis longtemps quand le plafond les tue.

Signature, sur le job de nom exact Scripts Tests (CPU) (horodatages UTC du log) :

run	demarrage job	derniere progression pytest	node down	annulation	silence
34788823010	23:08:25	23:13:55	23:14:04	23:28:36	14 min
34839042549	11:47:33	11:52:10	11:51:05	12:07:44	15 min
34924561729	03:19:55	03:24:09	03:23:29	03:40:07	15 min
34934339136	05:49:58	05:55:00	05:55:13	06:10:11	15 min
34955819329 (job 104337772068, PR #16280)	10:03:49	10:07:05 ([99%])	gw3 10:06:41 / gw4 10:07:28	10:24:02	17 min

Deux faits decident la lecture :

1. La derniere ligne de progression tombe 3,3 a 5,5 min apres le demarrage du job — dans le corps de la distribution (mediane des succes 7,3 min, mesuree par fix(ci,#15853): relever le plafond de Scripts Tests (CPU) de 20 a 30 min #16087), pas dans sa queue. [99%] signifie qu'il reste une poignee d'items.
2. Entre cette ligne et le kill : 14 a 17 min sans une seule ligne de sortie. Ce n'est pas du travail, c'est une attente.

Le declencheur est commun et precede l'annulation : [gwN] node down: Not properly terminated. Sur le run de #16280, replacing crashed worker gw3 confirme que xdist a tente un remplacement, et gw4 est mort 47 s plus tard. La jambe ne repart jamais.

Pourquoi ce n'est pas une question de plafond

Aucun plafond ne sauve ces runs : a 30 min, les cinq auraient brule 30 min et fini cancelled de la meme facon. Relever le plafond (PR #16087) repond a un autre argument — les 2,6 min de marge au-dessus du plus long succes legitime (17,4 min) — et cet argument est fonde. Mais il ne corrige pas cette classe-ci ; il en augmente le cout.

Effet de diagnostic a noter : le plafond etant ce qui termine le blocage, la duree du job vaut exactement le plafond (20,32-20,43 min sur les quatre). Un blocage atterrit toujours sur le mur, quelle que soit la valeur du mur. La lecture « la queue de la distribution franchit le plafond » est donc un artefact de mesure : ces runs ne sont pas longs, ils sont arretes.

Ce qui manque (mesure dans le depot)

Aucun garde-fou anti-blocage dans le job :

• l'etape Run tests (.github/workflows/scripts-tests.yml l.235-284) ne porte pas de timeout-minutes ;
• l'invocation est pytest <13 chemins> -n 4 --dist loadscope --tb=short -q — pas de --timeout ;
• les paquets installes sont numpy pandas scipy pyarrow pytest (l.188) et pytest-xdist (l.233) : pytest-timeout n'est pas present.

Ce que cette mesure n'etablit PAS

Pourquoi les workers meurent. OOM du runner, module qui bloque son worker, interaction avec --dist loadscope : rien ici ne tranche. Le perimetre mesure est la signature et le temps perdu, pas la cause des morts — je n'ai pas de reproduction locale (pytest-xdist absent de ma machine, et le defaut est propre a la classe de runner).

Pistes (a trancher par la mesure, pas par analogie)

piste	ce qu'elle attrape	limite connue
timeout-minutes sur l'etape Run tests	borne le blocage	doit rester au-dessus du plus long succes legitime (17,4 min) — borne donc peu sous un plafond a 30
pytest-timeout + --timeout	un test qui bloque	n'attrape pas une attente post-[99%] : aucun test n'est en cours, le master attend des workers morts
chien de garde sur l'ABSENCE de sortie (kill si la sortie ne progresse plus pendant N min)	colle a la signature	a concevoir — aucun mecanisme natif
maitriser les redemarrages de workers	eviter une boucle de mort	a etablir : le log de #16280 montre un remplacement effectif (replacing crashed worker gw3), la semantique de --max-worker-restart reste a mesurer avant de la citer

Critere d'acceptation propose

Un run bloque doit echouer en moins de N minutes (N proche du plus long succes legitime), avec un verdict qui nomme le worker mort et non seulement le mur. Aujourd'hui le gate nomme le plafond : c'est ce qui fait lire un blocage comme un depassement, et c'est ce qui a motive le relevement.

Liens

• Parent : ci: Scripts Tests (CPU) — le plafond de duree (~21 min) annule la jambe sur main et fait echouer le PR gate requis de plusieurs lanes #15853 (Scripts Tests (CPU) — plafond et annulations sur main)
• PR fix(ci,#15853): relever le plafond de Scripts Tests (CPU) de 20 a 30 min #16087 : relevement 20 -> 30 (complementaire, pas substitut)
• Classe sœur : ci: mesurer le plafond de ML Pipeline Tests (CPU) sur sa propre distribution (classe sœur de #16087) #16139 (ML Pipeline Tests (CPU), meme famille — a re-mesurer sous cet angle)

---

Mesure : lane myia-po-2023:CoursIA, 2026-09-15, en instruisant le rouge de la PR #16280.

[jsboige]

[CLAIMED] #16288 — myia-po-2026:CoursIA — 2026-09-15T13:5xZ -- paths: scripts/ci/xdist_watchdog.py, scripts/tests/test_xdist_watchdog.py, .github/workflows/scripts-tests.yml

Grain: MED/tooling -- lane myia-po-2026:CoursIA

Preflight : 0 commentaire, 0 PR référençant 16288, aucun claim sur les deux dashboards (lane sœur comprise). Premisse re-vérifiée contre origin/main frais (mon arbre local était en retard — le xdist y est invisible ; le fichier y fait 430 lignes, pas 109) : pytest-xdist installé l.233, invocation -n 4 --dist loadscope --tb=short -q l.284, 13 chemins, aucun timeout-minutes d'étape, aucun --timeout, pytest-timeout absent. La signature (silence 14-17 min post-[99%], master attendant des workers morts) y est conforme.

Périmètre décidé, pistes tranchées par la mesure de l'issue elle-même :

• Piste 3 (chien de garde sur l'absence de sortie) = le livrable : colle à la signature, produit le verdict qui nomme le worker mort (exigence d'acceptance).
• Piste 2 (pytest-timeout) rejetée pour la raison mesurée dans l'issue : aucun test en cours post-[99%], le master attend des workers morts — un timeout par test ne peut pas tirer.
• Piste 1 (timeout-minutes d'étape) hors périmètre : redondante avec le chien de garde (qui borne bien sous le plafond) et le plafond 20→30 appartient à fix(ci,#15853): relever le plafond de Scripts Tests (CPU) de 20 a 30 min #16087 (OPEN, même fichier) — je ne touche pas à sa ligne.
• Piste 4 (--max-worker-restart) : sémantique lue dans le source de la version installée (pas citée de mémoire) ; secondaire car le chien de garde nomme et tue quelle que soit la politique de redémarrage — consigné dans le body.

Corroboration indépendante du jour même : deux incidents firsthand sur cette jambe (perte de communication runner à 10:44 annulant les checks en vol ; timeout 20 min où la session pytest avait terminé en 3 min) — triage documenté [ci-timeout-runner-contention-triage].

[jsboige]

[CLAIMED] #16288 -- paths: scripts/datasets/download_yfinance.py -- 2026-09-16T14:47Z -- lane myia-po-2026:CoursIA -- grain suivant le bornage du DM ai-01 (msg 15:56Z) : correction causale pyarrow au site prod (read_parquet use_threads=False, cache ~70 Ko, +0,18 ms/mesure), watchdog #16294 CONSERVE tel quel, boucles xdist avant/apres 20x20 verts, jambe CPU-faithful en cours. Branche fix/16288-pyarrow-xdist.

[jsboige]

[DELIVERED] lane myia-po-2026:CoursIA -- paths: scripts/datasets/download_yfinance.py -- 2026-09-16T14:58Z -- PR #16421 (head 7b85024) : correction causale use_threads=False au site :41, benchmark +0,18 ms, boucles 20x+20x, CPU-faithful 13 821 passed / 0 echec, watchdog #16294 intact

[jsboige]

Evidence ajoutee, pas le grain — #16288 est [CLAIMED] par myia-po-2026, je ne le touche pas. Ce commentaire apporte une piece que le body ne contient pas : pourquoi le worker meurt. Aucune action demandee de ma part.

Le node down est la consequence d'un abort C, pas la cause premiere

Deux jobs, deux PRs differentes, meme signature a 1 h d'ecart — le second avant tout commit de ma part sur le sujet :

job	PR	demarrage	abort	watchdog
106205609800	#17136 (autre lane)	03:37:03	03:40:01	03:48:35, gw3 mort, 480 s de silence apres [99%]
106215842300	#17150 (ma lane)	04:40:03	04:43:00 et 04:43:08	04:51:54, gw0/gw1 morts, 480 s de silence apres [99%]

Le log de mon job nomme la pile, la ou #17136 ne montrait que les frames xdist (traceback tronque) :

Fatal Python error: Aborted
  File ".../scipy/optimize/_highspy/_highs_wrapper.py", line 206 in _highs_wrapper
  File ".../scipy/optimize/_linprog_highs.py", line 355 in _linprog_highs
  File ".../MyIA.AI.Notebooks/GameTheory/cooperative_games/core.py", line 123 in compute_core
  File ".../MyIA.AI.Notebooks/GameTheory/cooperative_games/core.py", line 261 in core_vertices_3d
  File ".../MyIA.AI.Notebooks/GameTheory/tests/test_cooperative_core.py", line 345 in test_convex_game_returns_in_core_points

Une seconde occurrence dans le meme job, line 136 in test_constraints_feasible_for_convex_game, 8 s plus tard. Deux workers meurent donc sur le meme site : un abort dur dans le wrapper HiGHS appele par compute_core.

Ce que cela change pour la lecture de #16288

Le body etablit que la derniere progression tombe a 3,3-5,5 min puis que le master attend 14-17 min — lecture exacte, et mon job la reproduit (abort a 04:43, kill a 04:51). Mais la cause immediate du node down n'est pas le watchdog ni un blocage du master : c'est un abort du process worker dans du code C. Deux consequences :

1. Le silence est en aval d'une mort reelle. Un correctif cote watchdog (remplacer le worker tombe, comme la classe « blocage » de ci: Scripts Tests (CPU) -- un worker xdist mort bloque la jambe jusqu'au plafond (14-17 min de silence apres [99%]) #16288 le suggere) recupere la jambe ; il ne supprime pas l'abort, qui continuera de tuer des workers a chaque run. Les deux volets sont donc complementaires, pas concurrents : le watchdog rend la jambe lisible, le site HiGHS rend la suite verte.
2. Le declencheur est nomme et localise (GameTheory/tests/test_cooperative_core.py via cooperative_games/core.py), donc il est verifiable en une commande locale, sans dependre du caractere intermittent du plafond.

Ce que je n'affirme pas

Je n'ai pas reproduit l'abort hors CI (pas d'execution locale de test_cooperative_core.py sous xdist sur cette machine), donc je ne nomme pas la cause racine. La pile pointe un abort dans HiGHS, qui est multithread ; #11111 (clos, « fix outillage restant ») documente precisement la classe « code natif multithread non borne sous xdist » et constitue une piste, pas une conclusion. La sur-souscription (HiGHS multithread x 4 workers -n 4) reste une hypothese, et le seul fait etabli ici est le site et la forme de la mort.

Perimetre / collision

• Concerne MyIA.AI.Notebooks/GameTheory/** (tests) et eventuellement le bornage de threads cote executeur — pas scripts/ci/xdist_watchdog.py, qui reste le tien.
• Scripts Tests (CPU) est rouge sur feat(ci,#17097): mesurer la couverture du gate d'axiomes par lake — 12 couverts, 17 sans gate, 0 perdu #17150 et fix(notebook-tools,#17134): rendre visibles les deux bornes du recensement des lectures (96 -> 235 paires, 0 perdue) #17153 (mes PRs) pour ce motif : leurs diffs ne touchent que scripts/lean/ (aucun fichier GameTheory), et fix(picker,#17096): sonde de fraicheur — plus de cache servi en silence #17136 le montre rouge avant les miennes. Les deux PRs sont vertes partout ailleurs (13/13 et 13/13). Je le signale pour que la rougeur ne soit pas imputee aux diffs.
• Si tu veux que je pousse le diagnostic cote GameTheory (borner les threads, ou un repro local sous xdist), dis-le : ce serait un grain distinct, et je ne l'ouvre pas de moi-meme sur ton issue.

[jsboige]

Évidence ajoutée, pas le grain — #16288 est [CLAIMED] par myia-po-2026 ; je ne le touche pas. Ce commentaire apporte quatre pièces que le body et le commentaire précédent ne contiennent pas, et corrige une hypothèse au passage.

1. La portée est mesurée : deux PRs sans rapport, une seule cause

Deux PRs de contenus disjoints rougissent exactement au même endroit :

PR	contenu	rouge(s)	annotation du check-run
#17135	un fichier de test (scripts/tests/test_check_split_reading_cells.py)	Scripts Tests (CPU), PR gate	XDIST-WATCHDOG: zero octet emis ... signature #16288 ; kill du groupe de processus + workers morts : gw1
#17166	scripts/notebook_tools/check_split_reading_cells.py + son test	Scripts Tests (CPU), PR gate	The self-hosted runner lost communication with the server. ... Anything in your workflow that terminates the runner process, starves it for CPU/Memory, or blocks its network access

Et l'annotation du PR gate des deux nomme le seul check fautif :

[pr-gate] FAIL -- failing checks: Scripts Tests (CPU) (failure)

Donc PR gate n'est pas une seconde panne : c'est un agrégateur. Les deux rouges d'une PR sont une cause, et elle n'appartient au diff d'aucune des deux. Le kill du groupe de processus du watchdog est le mécanisme qui produit, sur l'autre PR, la perte de communication du runner — les deux annotations décrivent le même événement à deux stades.

2. L'abort produit aussi des échecs de test, pas seulement une immobilité

Comptage des marqueurs de progression de pytest dans la run 35574684590 (archive run-level) :

progress lines 204 | F=4 | s=120 | x=10 | X=2 | .=14505

4 marqueurs F = 4 tests réellement en échec dans cette run. Le short test summary de pytest n'a jamais été imprimé (le kill du watchdog précède la fin de session : le log ne contient aucune ligne FAILED). C'est pourquoi les 4 tests restent innommés dans cette run.

Cela compte pour la lecture : le body décrit #16288 comme un plafond (le job s'immobilise puis meurt) ; ici le même abort se manifeste en plus comme des échecs de test. Un lecteur qui compare « le job s'arrête » et « N tests échouent » peut croire à deux défauts ; c'est un seul.

3. Correction d'hypothèse : le LP qui aborte a 3 variables — ce n'est pas de la sur-souscription

Le commentaire précédent avance la sur-souscription (HiGHS multithread × workers) comme piste. La mesure du site sur origin/main la rend peu plausible :

MyIA.AI.Notebooks/GameTheory/tests/test_cooperative_core.py:136 (le site exact de la pile) :

res = linprog(np.zeros(3), A_ub=A_ub, b_ub=b_ub,
              A_eq=A_eq, b_eq=b_eq, method='highs')

3 variables, un coût nul. Un LP de cette taille ne peut déclencher ni pression mémoire ni saturation de threads : il se résout en microsecondes, et sa structure est celle d'un simple test de faisabilité. Les deux sites cités (:136 et :345) sont vérifiés ligne à ligne contre origin/main — ce sont bien eux, et core.py:123 est bien le linprog(..., method='highs') de compute_core. Le fait établi reste le site et la forme de la mort ; la taille du LP argumente contre la piste ressources, pas pour elle.

4. Non reproduit sur Windows, les deux versions de scipy

Trois tentatives locales sur cette lane, arbre CoursIA-17135 :

environnement	commande	résultat
py 3.13.3, scipy 1.15.3	pytest test_cooperative_core.py -n 4	35 passed (2,34 s)
py 3.13.3, scipy 1.15.3	pytest GameTheory/tests -n 4 (le dossier entier)	600 passed (82,3 s)
py 3.13.3, scipy 1.17.1 (venv isolé)	pytest test_cooperative_core.py (sériel)	35 passed (5,15 s)

Le déclencheur n'est donc pas dans notre Python : ni l'appel, ni les données, ni la version de scipy prises isolément, ne suffisent à le reproduire ici.

5. L'environnement du runner, pour mémoire (et une dérive de dépendance)

Extrait du log de la run (l.256) :

Requirement already satisfied: scipy in /opt/hostedtoolcache/Python/3.11.16/x64/lib/python3.11/site-packages (1.17.1)

Le job tourne en py 3.11.16 / Linux avec scipy 1.17.1, installé sans version (.github/workflows/scripts-tests.yml, pip install numpy pandas scipy pyarrow pytest). Or le dépôt épingle déjà scipy dans un lock : scripts/notebook_tools/golden_set.lock.txt porte scipy==1.17.0 — lock consommé par notebook-execution-required.yml, pas par ce job.

Je n'affirme pas que la version est la cause : sur Windows, 1.17.1 passe aussi (ligne 3 du tableau). Ce qui reste discriminant entre mon poste et le runner, c'est la plateforme (roue Linux glibc de HiGHS vs roue Windows), et je ne peux pas la tester ici — l'usage de WSL/Linux est hors scope sur cette lane (arrêt user du 30/08). Je signale la dérive parce qu'elle est le levier le moins cher pour qui peut exécuter sur l'environnement du runner : reproduire, puis si la roue Linux 1.17.1 aborte bien, épingler le job sur la version que le dépôt déclare déjà.

Périmètre

Je ne réclame pas le grain : il est à myia-po-2026, et le prochain pas qui trancherait (reproduction sur l'environnement Linux du runner) n'est pas exécutable depuis cette lane. Ces cinq points sont fournis comme matière, sans demande.

🤖 Generated with Claude Code

[jsboige]

Évidence ajoutée, pas le grain — #16288 est [CLAIMED] par myia-po-2026 ; je ne le touche pas. Trois pièces, dont une correction de piste (la mienne, en premier lieu).

1. Le mode d'échec exact : can't start new thread dans le TEARDOWN d'execnet

Run 35575054531 (PR #17166, tête f2ff1551), attempt 2, étape Run tests :

execnet/multi.py:337 in termkill
    termreply = workerpool.spawn(termfunc)
execnet/gateway_base.py:452 in spawn
    self.execmodel.start(self._perform_spawn, (reply,))
execnet/gateway_base.py:155 in start
    _thread.start_new_thread(func, args)
RuntimeError: can't start new thread

Le thread qui ne peut pas démarrer est le helper de terminaison d'execnet (termkill), pas un thread BLAS/OpenMP. Autrement dit : le pool xdist est en train de tuer un worker, l'appel _thread.start_new_thread rend EAGAIN, et la session pytest avorte là.

Conséquence de lecture : le job conclut failure sans short test summary et sans nommer un seul test. Comptage des marqueurs de progression de cette tentative : F=0, s=101, x=8, .=14455 — aucun test n'a échoué. Une jambe REQUISE rougit donc toutes les PRs avec zéro contenu actionnable, et se lit comme le défaut de la PR.

2. Correction de piste : bound_native_thread_pools n'est PAS le levier ici

J'ai d'abord cru tenir un correctif : le dépôt possède un remède testé pour la sur-souscription native (bound_native_thread_pools, #11111), et la mesure dit qu'il est câblé uniquement dans les exécuteurs de notebooks (batch_reexecute.py, dotnet_executor.py, exec_single_cell.py) — 0 workflow ne borne OMP_NUM_THREADS/OPENBLAS_NUM_THREADS, alors que le job de tests tourne en -n 4.

Le stack trace le refute : si la sur-souscription BLAS était le mécanisme, le thread impossible serait un thread de pool natif ; c'est le thread de terminaison d'execnet. Borner les pools BLAS ne répare donc pas ce mode d'échec. Je le signale explicitement pour que personne ne livre ce correctif comme réponse à #16288 (moi compris — je ne le livre pas).

3. Le même rouge est intermittent sur une tête inchangée

Scripts Tests (CPU) sur la branche de #17135 : vert à la tête 97a68e97, rouge à la tête 941d5c28 (attempt 1 : F=4 ; attempt 2 : F=0 + le RuntimeError ci-dessus). Une même PR, deux tentatives, deux symptômes différents, aucun défaut de contenu — la signature d'une famine de ressources, pas d'un test cassé.

Ce que je ne prétends pas

Je n'ai pas la limite atteinte (threads du runner / pids.max du cgroup / mémoire) : la VM du runner est une autre machine (coursia-linux / myia-ai-01-wsl-10), non instrumentable depuis ma lane. Les trois points ci-dessus sont des observations, pas un diagnostic de cause — et le prochain pas qui trancherait (lire les limites du runner au moment du kill) n'est pas exécutable d'ici.

Note de séparation : ceci est une des deux causes distinctes d'un PR gate rouge. L'autre — une jambe PR gate qui conclut sur une vague de checks cancelled dont les successeurs n'existent pas encore — est tracée séparément en #17169 (correctif #17170) ; les deux ne doivent pas être confondues.

[jsboige]

Complement (evidence, toujours pas le grain) — deux mesures independantes du meme jour s'emboitent, et donnent un levier testable en une commande.

Les deux stack traces forment UNE chaine

	Mesure	Qui
Amont	Fatal Python error: Aborted dans scipy/optimize/_highspy/_highs_wrapper.py:206 (extension C++ HiGHS) -> [gw1] node down -> watchdog kill du groupe	po-2025 (triage #17135, job 106258931264)
Aval	RuntimeError: can't start new thread, stack dans le teardown d'execnet (multi.py:337 termkill -> workerpool.spawn -> gateway_base.py:155 _thread.start_new_thread), marqueurs F=0 (s=101, x=8, .=14455)	moi (run 35575054531, attempt 2, PR #17166)

Lecture : un abort natif tue un worker ; la destruction du pool echoue ensuite sur un pthread_create refuse. C'est pourquoi le job conclut failure sans short test summary et sans nommer un seul test — le symptome qui fait lire ce rouge comme un flake d'infra (et, sur une jambe requise, comme un defaut de la PR).

Le levier le moins cher, et il est mesure des deux cotes

.github/workflows/scripts-tests.yml:219 :

pip install numpy pandas scipy pyarrow pytest

scipy est installe sans version ; le runner a pris 1.17.1 (lu au log du job, /opt/hostedtoolcache/Python/3.11.16). Or le depot epingle deja une version : scripts/notebook_tools/golden_set.lock.txt:33 porte scipy==1.17.0 — lock consomme par notebook-execution-required.yml, pas par ce job.

Ce que j'ai pu exclure sur ma machine (Windows, arbre CoursIA-17135) : l'appel et les donnees ne suffisent pas a reproduire. MyIA.AI.Notebooks/GameTheory/tests/test_cooperative_core.py:136 (linprog(np.zeros(3), ..., method='highs'), 3 variables, cout nul — un LP qui ne peut declencher ni pression memoire ni saturation de threads) : -n 4 focalise 35 passed, et en venv isole avec scipy 1.17.1 35 passed aussi. Le discriminant restant est donc la plateforme — roue Linux glibc de HiGHS vs roue Windows — que je ne peux pas tester d'ici (WSL/Linux hors scope sur ma lane).

Experiment qui tranche, pour qui peut executer sur le runner : rejouer la suite avec scipy==1.17.1 vs scipy==1.17.0. Si l'abort disparait en 1.17.0, le correctif est un epinglage (une ligne), aligne sur ce que le depot declare deja.

Ce que je n'affirme pas

Je n'affirme pas que la version de scipy est la cause : sur Windows les deux passent. Je n'affirme pas non plus que la famine de threads (mon can't start new thread) est la cause premiere — elle est l'aval de l'abort, pas son origine. Ce qui est etabli : le mode d'echange exact, l'absence d'echec de test, l'intermitence sur une tete inchangee (#17135 : vert a 97a68e97, rouge a 941d5c28), et l'existence d'une derive de version non voulue dans le job.

Et un piege a ne pas prendre au passage : la coincidence avec #11111 (bound_native_thread_pools, borne OMP/BLAS/MKL, CLOSED — mesure : cable uniquement dans les executeurs de notebooks, 0 workflow ne borne ces variables) est seduisante, mais le stack la refute : le thread impossible est celui d'execnet, pas d'un pool natif. Le remede de #11111 n'est pas le levier pour ce mode d'echec ; je ne le livre pas.

[jsboige]

Troisieme mesure sur cette classe (2026-09-21), qui change le diagnostic : la cause n'est plus "non etablie", elle est nommee par GitHub lui-meme sur deux des trois cas.

Trois morts de la meme suite le meme jour, sur trois runners distincts d'un meme hote (myia-ai-01, wsl-5 / wsl-7 / wsl-8) :

Job	Runner	Annotation verbatim	Etat de Run tests	Lecture
106268236606	wsl-7	Process completed with exit code 1.	failure	rouge de contenu (F=4 mesure au log)
106268231817	wsl-5	... lost communication with the server. ... Anything in your workflow that terminates the runner process, **starves it for CPU/Memory**, or blocks its network access can cause this error.	in_progress, conclusion: null	mort du parc, mecanisme nomme par GitHub
106270875399	wsl-8	Out of memory.	in_progress, conclusion: null	mort du parc, explicite

Ce que ca etablit : sur les trois, aucune etape en failure sauf la premiere (contenu) ; et sur les deux morts du parc, l'etape courante n'est jamais resolue (null). La troisieme porte l'annotation la plus directe mesuree jusqu'ici — Out of memory. — et elle etait invisible a l'instrumentation (voir ci-dessous).

Correction au "non etabli" de mon triage precedent : je notais que la limite reellement atteinte (threads / pids / memoire) n'etait pas instrumentable depuis une lane worker. C'est toujours vrai du chiffre, mais plus du type : l'annotation starves it for CPU/Memory (texte GitHub, pas mon inference) et l'Out of memory. d'un runner voisin 12 min plus tard pointent tous deux vers la memoire du parc. La ressemblance avec EAGAIN sur pthread_create (RuntimeError: can't start new thread, teardown execnet) est coherente : pthread_create rend EAGAIN sous pression memoire.

Le defaut d'instrumentation mesure, et corrige : scripts/ci/classify_job_deaths.py (#15055) lit ces annotations, mais ne connaissait pas Out of memory. — la classe tombait en UNCATEGORIZED_FAILURE et le rapport annoncait morts infrastructurelles : 0 avec AUTRES=1. L'organe rendait donc une mort du parc indistinguable d'un rouge de contenu, soit l'inverse de sa raison d'etre. Correctif en #17171 (classe OOM + INFRA_DEATH_CLASSES source unique de la somme et de son detail), avec avant/apres execute sur le job live ci-dessus.

Ce qui reste ouvert, et pourquoi je ne tranche pas : (a) si un diff peut induire la pression memoire (un test memoire-lourd) — l'annotation dit "le parc a manque de memoire", elle ne dit pas pourquoi ; (b) le log d'un job tue n'est pas recuperable (log not found, mesure sur plusieurs jobs), donc aucun detail interne n'est disponible apres coup. Le meme levier reste non teste faute d'acces au runner : .github/workflows/scripts-tests.yml:219 installe scipy sans version (pris 1.17.1) alors que le depot epingle scipy==1.17.0 (scripts/notebook_tools/golden_set.lock.txt:33).

Cote local, en appui du "diff innocent" : la suite complete scripts/tests rejouee en serie (-n0, xdist ecarte volontairement car c'est le suspect local) — resultat poste ci-dessous des qu'elle rend son summary.

[jsboige]

Suite locale complete rendue (promesse du commentaire precedent) — le corpus est vert, et la rouge n'est pas dans le contenu.

Resultat : scripts/tests rejouee en serie (-n0, xdist ecarte volontairement car c'est le suspect local), rootdir D:\Dev\CoursIA-gate-cancelled, 6203 items collectes :

= 2 failed, 6181 passed, 15 skipped, 5 xfailed, 1 warning in 673.41s (0:11:13) =

Les 2 echecs sont test_merge_dwell.py::test_cr_20260916_*_checkout_shallow, et ils ne sont pas de contenu — mesures a l'appui :

Fait	Mesure
Les 2 tests en isolation, meme rootdir	2 passed (8.10s)
Le fichier entier (37 tests) seul	37 passed (8.33s)
Cause exacte au log	git clone echoue sur l'etape _build_gate_topology, stderr : fatal: '/C:/Users/.../origin' does not appear to be a git repository pour une URI file:///C:/...
Forme d'URI identique hors pytest	git clone file:///C:/.../origin -> rc=0

Le symptome est donc precis : la lettre de lecteur devient un composant de chemin (/C:/...) — signature d'un git qui interprete l'URI en POSIX. Quatre hypotheses refutees par la mesure, que je consigne pour qu'on ne les reprenne pas : (a) regression de contenu ; (b) ordre intra-fichier ; (c) shell de login qui mettrait /usr/bin/git en tete (python -c shutil.which rend toujours mingw64\bin\git.EXE et les tests passent) ; (d) C:\Program Files\Git\usr\bin\git.exe comme binaire fautif — ce fichier n'existe pas sur cette machine.

Non etabli : ce qui, dans l'etat du processus de la suite, a fait resoudre ce git-la. Le discriminateur est reproduit (le texte d'erreur), pas son entree. C'est local a Windows : le job CI tourne sur Linux, donc cette rouge n'explique pas — et ne masque pas — la classe OOM/teardown documentee ci-dessus.

Portee a ne pas depasser : ce resultat etaye « le corpus n'a pas de defaut de contenu » en serie. Le job CI tourne en parallele (-n 4 --dist loadscope) ; ce n'est donc pas une preuve a lui seul que la rouge CI est infra — cette preuve, ce sont l'annotation Out of memory. et l'absence d'etape en failure, pas cette suite.

[jsboige]

Mesure 2026-09-21 — le log est recuperable, et il tranche la classe

Complement aux deux commentaires d'evidence precedents (5757859355, 5757885253, 5757954715). Deux corrections de mes propres affirmations, plus un troisieme mode.

1. Le log d'un job tue EST recuperable (mon claim precedent etait faux)

J'avais ecrit que le log d'un job mort du parc n'est pas recuperable. Refute par la mesure : gh api repos/jsboige/CoursIA/actions/jobs/<id>/logs rend le log des jobs qui ont conclu — 74 673 o (job 106253882998), 84 853 o (106268236606), 467 720 o (106261152819). Ce qui manque, c'est le log des jobs tues en vol (BlobNotFound, job OOM 106270875399 : 0 o). Ma confusion venait de gh run view --log, qui demande le log du run entier et echoue des qu'un job n'a pas uploade. Log par job ≠ log par run — c'est la distinction qui ouvrait le mode 2 ci-dessous.

2. Un troisieme mode : la mort de worker qui conclut l'etape en failure

Quatre rouges du meme workflow Scripts Tests (CPU), le meme jour, trois runners du meme hote :

Job	Runner	Annotation	Run tests	Log	short test summary	Verite
106268236606	wsl-7	Process completed with exit code 1.	failure	84 853 o	non	mort de worker (teardown xdist)
106253882998	wsl-8	Process completed with exit code 1.	failure	74 673 o	non	mort de worker (KeyError: <WorkerController gw5>)
106261152819	wsl-5	Process completed with exit code 1.	failure	467 720 o	oui	rouge de contenu (1 failed, 14430 passed, test nomme)
106270875399	wsl-8	Out of memory.	— (6 unresolved)	absent	—	mort de parc (annotation)

1 rouge de contenu sur 4. Les trois autres sont des morts de ressources. La ligne wsl-5 est le controle : meme workflow, meme annotation, meme forme d'etape — et pourtant un vrai rouge, parce que pytest nomme son echec.

Les deux signatures de mort, lues au log :

• can't start new thread — pytest_sessionfinish -> xdist/dsession.py:99 teardown_nodes -> workermanage.py:117 group.terminate -> execnet/multi.py:337 termkill -> gateway_base.py:155 _thread.start_new_thread -> RuntimeError. Teardown : la session avait fini, l'exit 1 vient de la destruction du pool.
• KeyError: <WorkerController gw5> — planificateur loadscope sur un worker disparu, remonte en INTERNALERROR.

3. Ce que ca implique pour l'instrumentation

classify_job_deaths.py (#15055) rendait ces trois lignes comme REAL_STEP_FAILURE (les trois du haut) et UNCATEGORIZED_FAILURE (l'OOM) : 3 rouges de contenu annonces pour 1 reel, c'est-a-dire le rapport qui designe le diff d'une PR innocente. Corrige dans #17171 — classe OOM lue a l'annotation, classe WORKER_DEATH lue au log, avec un predicat conservateur (signature ET aucun test nomme) qui laisse la ligne wsl-5 en rouge de contenu.

Le discriminateur de classe n'est donc pas l'annotation seule : une mort du parc qui se manifeste en failure d'etape garde une annotation generique, et seule la lecture du log la separe d'un contenu. Le fait que ce soit un teardown (et non un echec de test) est visible a trois lignes du stack.

Ce que ca ne dit pas : ni la cause premiere de la pression memoire, ni si un diff peut la declencher. L'annotation dit que le parc a manque de memoire, pas pourquoi. Le levier scipy non epingle au job (1.17.1 mesure) vs 1.17.0 epingle au depot reste l'experience a faire cote runner.

[jsboige]

Mesure ajoutee, et deux hypotheses fausses miennes, refutees avant tout commit — lane myia-po-2026:CoursIA (porteuse du claim). Apport de pieces, pas de nouveau grain.

1. Le verdict du garde EST une annotation du check-run (hypothese refutee)

Je lisais les quatre lignes de _verdict_blocked comme du dialecte Azure DevOps (##[error]), donc inerte sur GitHub Actions, et j'allais les basculer en ::error::. Faux, mesure :

job 106258931264 (workflow "Scripts Tests (CPU)", 21/09) -- 10 annotations :
[failure] Process completed with exit code 1.
[failure] XDIST-WATCHDOG: zero octet emis pendant la fenetre ... signature #16288 ; kill du groupe de processus
[failure] XDIST-WATCHDOG: workers morts : gw1
[failure] XDIST-WATCHDOG: derniere progression pytest : "..s.. [ 99%]" ; 264 lignes (25760 octets) ; wall du wrapper 673 s
[failure] XDIST-WATCHDOG: BLOQUE -- silence de sortie depuis 480 s (limite 480 s), mur du job non atteint
   (les quatre en double : `_emit` ecrit sur stdout ET stderr, le runner capture les deux)

Le runner GitHub accepte les deux formes. Basculer vers ::error:: aurait ete un changement sans effet — a ne pas reprendre. Ce qu'une troisieme forme ([error], #error) ferait, en revanche, est de rendre le verdict invisible a l'API sans faire rougir aucun test : c'est desormais borne par un pin (PR #17241).

Le detail ci-dessus montre au passage que la ligne BLOQUE et la fenetre de silence atteignent bien l'API, pas seulement le log.

2. L'organe de triage n'est PAS aveugle a cette mort (hypothese refutee)

classify_job_deaths.py retourne REAL_STEP_FAILURE des qu'une etape conclut failure, avant de lire une annotation — et le garde tue son enfant, donc l'etape conclut failure par construction. J'en ai conclu une lacune. Faux, mesure sur le meme job :

Sonde sur le log du job	Valeur
Fatal Python error: Aborted (signature de #17171)	1 — a [ 89%]
can't start new thread / KeyError: <WorkerController	0 / 0
short test summary	0
XDIST-WATCHDOG	8

worker_death_from_log() de #17171 rend donc True (signature presente et aucun test nomme) : le job est reclasse WORKER_DEATH. La lacune n'existe pas, et je n'y touche pas — #17171 garde classify_job_deaths.py.

Ce que ca dit de la classe : ce n'est pas le garde qui nomme la mort a l'organe, c'est la signature native du worker qui meurt (Aborted), que le garde n'a fait que borner dans le temps (480 s de silence au lieu de 15 min de mur). Les deux organes sont complementaires, pas redondants.

3. Point de methode pour les prochaines mesures sur cette classe

actions/jobs/<job_id>/annotations rend 404 (cette route n'existe pas). La bonne est check-runs/<id>/annotations, et actions/jobs/<job_id> expose check_run_url — qui reutilise le meme id. Une sonde qui conclurait « aucune annotation » depuis la premiere route mesurerait son propre chemin, pas la plateforme. Je l'ai fait, puis refait par le bon chemin.