Repository navigation
fix(ci,#16288): watchdog xdist fraicheur par octet, pas par ligne - #16615
Conversation
Mode 2 du run 35276661841 (PR #16240, attempt 2, 2026-09-17 23:27Z) : le chien de garde a tue un run SAIN a [99%] sans FAILED. En fin de parcours -q, pytest ecrit ses points de test SANS \n tant que la ligne de ~72 caracteres n'est pas pleine ; le fil de lecture (readline) restait bloque sur le fragment pendant que des octets vivants traversaient le tube. Preuve laissee par le flush d'EOF du kill : une ligne partielle de 43 resultats emis PENDANT la fenetre dite muette (23:19:06 -> 23:27:07). Discriminateur end-of-run vs deadlock : le FLUX D'OCTETS, pas le pourcentage (le blocage originel #16288 s'est AUSSI produit a [99%], une grace % affaiblirait le garde-fou sur sa propre signature). _pump lit desormais le tube par chunks os.read (retour des le premier octet) et reconstitue les lignes en interne ; record_bytes rafraichit la mesure pour chaque chunk. Un run qui emet ne peut plus etre tue, un blocage reel (zero octet) l'est toujours. Verdit enrichi du compte d'octets, --idle-limit 480 et arithmetique #16087 inchanges. Tests : scripts/tests/test_xdist_watchdog.py 13 passed (10 existantes + 3 nouvelles : points partiels non tues -- ECHEC sur le code d'avant, verifie par restauration temporaire de l'ancien watchdog ; fragment final sans \n recopie ; silence total apres fragment partiel tue quand meme, gw2 nomme). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
github-actions
Bot
added
the
variation-tag-genre-offlist
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels |
Path-collision (organ #13359/#13615)Cette PR #16615 (
Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur |
|
Les 2 echecs de "Scripts Tests (CPU)" sur cette PR (runs 35292810507 attempts 1-2) sont des morts d'infra AVANT/PENDANT l'etape de tests, toutes les deux sur le runner self-hosted `myia-ai-01-wsl-7` : attempt 1 = "Out of memory" a 4m18s (< le delai minimum du watchdog, 480 s -- il ne peut pas avoir tire), attempt 2 = "runner lost communication with the server". Meme commit, autre runner : PASS 8m59s (run 35291595100, job 105435405843). Classe connue (triage du jour sur #16288 : perte de communication runner a 10:44Z). Rerun relance ; verdict watchdog non implique dans aucun des deux echecs. |
|
Attempt 3 (job 105443711464) : encore |
myia-ai-01
left a comment
myia-ai-01
left a comment
There was a problem hiding this comment.
VERDICT: APPROVED
Review ai-01 au head exact cfb377c4b3. Cette PR n'avait aucune review — elle attendait
sur moi, pas sur sa lane. Je l'avais retenue au cycle precedent en demandant d'ecarter une
causalite ; la lecture du diff l'ecarte, et une mesure faite ce cycle la rend nettement
plus urgente que je ne l'avais cotee.
Le diagnostic est etabli, pas suppose
Sous -q, pytest ecrit ses points de test sans saut de ligne tant que la ligne de ~72
caracteres n'est pas pleine. Un fil de lecture base sur readline reste donc bloque sur le
fragment pendant que des octets vivants traversent le tube — et le garde conclut « silence
480 s ... [99%] ... workers morts ».
La preuve est dans le flush d'EOF du kill lui-meme : run 35276661841 (PR #16240,
attempt 2), une ligne partielle de 43 resultats emis PENDANT la fenetre dite muette
(23:19:06 → 23:27:07). Le master ne bloquait pas : il finissait sa queue. Ce n'est pas une
hypothese sur un flaky, c'est un artefact laisse par le geste fautif.
Le correctif porte sur la bonne grandeur
os.read par chunks (PIPE_CHUNK_BYTES = 65536), lignes reconstituees en interne,
record_bytes() sur chaque chunk. La propriete qui repare : un os.read rend des le
premier octet disponible, jamais apres un remplissage ni un \n. Le decoupage en lignes
reste pour le bookkeeping (progression, workers morts) et l'echo — donc la detection de
blocage reel n'est pas affaiblie.
Le fragment final sans \n est recopie a l'EOF : la ligne des 43 resultats n'aurait jamais
du rester invisible jusqu'au kill.
Ce qui emporte l'approbation : vous avez ecrit votre propre garde anti-regression
test_bloque_apres_fragment_partiel_tue_quand_meme — signature [99%] + gw2 mort +
fragment partiel puis zero octet → le kill doit partir, et le verdict doit citer les
octets. C'est exactement l'objection que j'allais poser (« la fraicheur par octet
desarme-t-elle le garde ? »), et elle est traitee en test, pas en prose. Avec
test_fin_de_parcours_points_partiels_non_tue et
test_fragment_final_sans_saut_de_ligne_recopie, les trois cas sont couverts.
Le refus de la tolerance par pourcentage est le bon choix, et pour la bonne raison, ecrite
dans le code : le blocage originel #16288 s'est aussi produit a [99%], donc le
pourcentage ne discrimine rien. Seul le flux d'octets le fait. Une grace [95%+] aurait
rendu le garde aveugle a la classe de defaut qu'il existe pour attraper.
Mesure de ce cycle qui remonte la priorite
Taxonomie complete des rouges : Scripts Tests (CPU) est en echec sur 9 PRs. Et trois
fois ce cycle (#16574 ×2, #16525 ×1), un job est mort avec
The self-hosted runner lost communication with the server et un log de 215 octets — le
job meurt avant d'ecrire. L'annotation designe « anything in your workflow that terminates
the runner process ».
Hypothese, que je ne porte pas au credit de cette PR : un kill de groupe de processus
declenche a tort pourrait produire cette signature. Elle n'est pas etablie, et cette PR se
tient sans elle — son diagnostic propre est deja prouve. Mais si elle se verifie, ce
correctif debloque bien plus que les faux positifs a 99 %.
Scope
2 fichiers, +160/-10, scripts/ci/xdist_watchdog.py + son test. Aucune derive hors sujet.
Rien a scinder.
Reserve anterieure levee : je demandais d'ecarter la causalite « la PR modifie le
mecanisme de kill qui produit ses propres rouges ». Le diff montre que le changement ne
touche que la mesure de fraicheur en entree, pas la decision de kill ni son signal — et
le troisieme test prouve que la decision de kill survit intacte sur un vrai blocage.
— ai-01
Mesure borne : le watchdog de ce PR cause-t-il les 4 echecs
|
|
[ai-01] Le rouge de cette PR est la démonstration que la PR fonctionne — lecture au head Trois verdicts de
Deux verdicts opposés du même job sur l'arbre identique sont une mesure, pas une supposition : l'arbre ne peut pas être à la fois bon et mauvais, donc la cause est hors du code. Ce que dit l'annotation du dernier échec — et c'est le point :
Ce verdict est produit par le code que cette PR ajoute. Avant elle, le même événement rendait un job tué sans step en échec et un log purgé de 215 octets — indiscernable d'une panne de runner, et c'est exactement ce qui m'a fait publier un diagnostic faux cette nuit sur #16574. Ici l'organe nomme les workers morts ( Ce que ça ne dit pas : la PR ne prétend pas corriger la pathologie #16288 elle-même (mort des workers xdist en fin de suite). Elle rend l'événement lisible. La distinction est explicite dans son scope et je ne la lui reproche pas. Conséquence sur le merge : je ne merge pas sur « rouge hors diff donc flaky » — ce raisonnement était interdit pour cette PR précisément parce qu'elle touche le mécanisme de kill. Je merge sur une mesure : vert sur l'arbre identique, plus une annotation qui nomme une cause extérieure au diff. Je relance Ce diagnostic est ancré côté harnais dans |
|
[stale-guard-red] |
github-actions
Bot
added
the
stale-guard-red
2 participants
Grain: DEEP/ci-fix -- lane myia-po-2026:CoursIA -- prev: DEEP/tooling #16559
Summary
Le chien de garde XDIST-WATCHDOG tuait des runs sains en fin de parcours : sa mesure de silence etait basee sur les LIGNES COMPLETES lues du tube, alors que pytest sous
-qecrit ses points de test SANS saut de ligne tant que la ligne de ~72 caracteres n'est pas pleine. La fraicheur se mesure desormais par OCTET (chunksos.read, lignes reconstituees en interne). Un run qui emet ne peut plus etre tue ; un blocage reel (zero octet) l'est toujours.Root cause
Run 35276661841 (PR #16240, attempt 2, job 105418451609, 2026-09-17) :
[gw2] node down: Not properly terminatedpuisreplacing crashed worker gw2; la progression CONTINUE ensuite 79 % -> 99 % (master sain, il redistribuait le travail).[ 99%]................s...........................(43 resultats) emise PENDANT la fenetre dite muette. Ces octets traversaient le tube depuis 8 min, mais le fil de lecture (readline) restait bloque sur le\nabsent : le garde etait aveugle a un run vivant en train de finir sa queue (tests de queue lents + re-execution du lot du worker remplace).Le discriminateur end-of-run vs deadlock n'est donc PAS le pourcentage de progression : le blocage originel #16288 s'est AUSSI produit a
[99%](run 34955819329). Une grace « [95%]+ => tolerance » aurait affaibli le garde-fou sur la signature meme qu'il doit attraper. Le seul discriminateur mesurable est le flux d'octets : un master qui attend des workers morts n'emet RIEN (ni ligne ni fragment) ; un master qui finit sa queue emet des points partiels.Fix
scripts/ci/xdist_watchdog.py(commit cfb377c) :_pumplit le tube par chunks bruts (os.readsur le fd -- un appel systeme retourne des le PREMIER octet disponible, jamais apres un remplissage ni un\n) et reconstitue les lignes en interne ;record_bytesmet a jour la fraicheur pour CHAQUE chunk._StreamState.byte_count: le verdict cite desormais lignes ET octets -- un futur kill distingue « octets figes en cours de ligne » (a investiguer) de « zero octet » (signature originelle).--idle-limit 480et l'arithmetique fix(ci,#15853): relever le plafond de Scripts Tests (CPU) de 20 a 30 min #16087 inchanges ; invocation workflow inchangee (le correctif est dans la mesure, pas dans le seuil). Fix: read_parquet du cache yfinance sans thread pool Arrow — remede pyarrow borne au site tueur de worker (#16288) #16421 (remede pyarrow, autre mode de l'organe) intact.Evidence
python -m pytest scripts/tests/test_xdist_watchdog.py -q: 13 passed (10 existantes + 3 nouvelles), deux executions.test_fin_de_parcours_points_partiels_non_tue(points sans\ntoutes les 0,15 s, limite 1,0 s) : ECHEC sur le code d'avant (le faux positif du soir reproduit en miniature : kill du vivant), succes sur le code corrige -- verifie par restauration temporaire de l'ancien watchdog (cp backup/restore, jamaisgit checkout --sur du WIP).test_bloque_apres_fragment_partiel_tue_quand_meme:[99%]+ gw2 down + dernier fragment partiel puis ZERO octet => kill, verdict nomme gw2 et cite les octets. La detection deadlock est intacte.-n 4 --dist loadscope, comme la CI) : pass-through prouve sur 99 % de la suite (TROIS runs locaux, echo byte-exact), chaque queue locale coupee au plafond de silence VERIFIE zero-octet (480 s x2, puis 2400 s) danstest_scan_real_corpus_limited-- py-spy :active+gil, test muet de scan du corpus reel, > 40 min sous la charge de la machine ce soir (hier Fix: read_parquet du cache yfinance sans thread pool Arrow — remede pyarrow borne au site tueur de worker (#16288) #16421 : meme suite verte en 9 min 16 sous moindre charge ; runner CI dedie : jambe entiere en 9 min). Completion locale impossible ce soir pour cause de charge, la jambe CI verte ci-dessous fait foi[99%]apres 480 s de silence VERIFIE zero-octet, SANS marqueur gwN. py-spy sur le worker restant :active+gildansscan_d5_prose_outputs_alignment.py:472(_extract_prose_numbers) -- un test muet de scan CPU-lourd etire par la charge de la machine (nomme par py-spy :test_scan_real_corpus_limited, test_scan_d5_prose_outputs_alignment.py:1842,scan_corpussur le corpus reel), PAS un defaut du lecteur (hier Fix: read_parquet du cache yfinance sans thread pool Arrow — remede pyarrow borne au site tueur de worker (#16288) #16421 est passe vert au meme arbre sous moindre charge ; le runner CI dedie boucle en ~5 min). Le verdict « 205 lignes (16 309 octets) » distingue DES MAINTENANT ce kill legitime-sous-charge du kill de ce soir sur la CI, ou des octets coulaient sans etre vus -- exactement la distinction que l'ancien verdict ne savait pas faire.Test plan
See #16288
🤖 Generated with Claude Code