Skip to content

test(ci,#16288): pinner la lisibilite du verdict xdist et sa mise en vigueur - #17241

Merged
myia-ai-01 merged 1 commit into
mainfrom
fix/16288-watchdog-annotation
Sep 22, 2026
Merged

myia-ai-01 merged 1 commit into
mainfrom
fix/16288-watchdog-annotation

Conversation

@jsboige

@jsboige jsboige commented Sep 21, 2026

Copy link
Copy Markdown
Owner

Grain: LIGHT/guard -- lane myia-po-2026:CoursIA -- prev: DEEP/notebook-python #16844

See #16288 — ne resout pas l'issue (le blocage lui-meme est traite) : ce PR pinne deux proprietes dont la disparition serait silencieuse.

Deux hypotheses fausses, refutees par la mesure avant le commit

1. Le prefixe ##[error] n'annoterait rien. J'avais lu les quatre lignes de verdict comme du dialecte Azure DevOps, donc inerte sur GitHub Actions, et j'allais le basculer en ::error::. Mesure sur le job 106258931264 (workflow Scripts Tests (CPU), 21/09) : le check-run porte 8 annotations XDIST-WATCHDOG, verbatim XDIST-WATCHDOG: workers morts : gw1, produites par ces memes lignes ##[error]. Le runner GitHub accepte les deux formes. La bascule aurait ete un changement sans effet.

2. L'organe de triage serait aveugle a cette mort. classify_job_deaths.py retourne bien REAL_STEP_FAILURE des qu'une etape conclut failure — avant de lire la moindre annotation — et le garde tue son enfant, donc l'etape conclut failure par construction. Mais sur le job cite, le log porte Fatal Python error: Aborted (a [ 89%], l'une des signatures de #17171) et aucun short test summary : worker_death_from_log() rend True, donc la PR #17171 deja approuvee reclasse ce job en WORKER_DEATH. Il n'y avait pas de lacune a combler, et je n'y touche pas.

Les deux refutations sont consignees dans le code, au site qu'elles concernent : la prochaine lane ne les reprendra pas.

Ce qui restait, et que rien ne pinnait

Deux proprietes dont la perte est silencieuse — aucun test ne rougit, le blocage revient simplement :

  1. Le verdict est une annotation du check-run. C'est la seule surface ou un lecteur qui n'a que le check-run voit le blocage nomme (le worker mort, la fenetre de silence). Toutes les lignes doivent porter le prefixe, pas seulement la premiere : une ligne laissee nue disparait de l'API et le verdict devient partiel.
  2. Le garde est reellement en vigueur. Il n'existe que parce que scripts-tests.yml enveloppe l'invocation pytest sur une ligne unique. Une edition de workflow qui la retire ramene la classe ci: Scripts Tests (CPU) -- un worker xdist mort bloque la jambe jusqu'au plafond (14-17 min de silence apres [99%]) #16288 — 14 a 17 min de silence puis le mur — sans temoin. Precedent de la meme famille : ci(#16099 followup): wire tests/test_evict_orphan_caches.py into PR Scripts Tests (CPU) #16422, une suite de tests ecrite par personne, cablee nulle part.

Preuves

Suite : 16 passed (13 avant, +3). Non-regression du voisinage : 22 passed sur test_xdist_watchdog.py + test_check_testpaths_coverage.py.

Falsification des trois pins — mutation, rouge attendu, restauration verifiee :

Mutation Test qui rougit
prefixe retire d'une seule ligne de verdict test_chaque_ligne_de_verdict_est_une_annotation
troisieme dialecte ([error], qui n'annote rien) test_le_prefixe_est_un_dialecte_du_runner_github
enveloppe du garde retiree de scripts-tests.yml test_le_workflow_cable_le_garde_autour_de_pytest

Controle de non-vacuite — ma premiere version du test de cablage ecrivait assert "pytest" in <texte apres le garde>, satisfait par echo pas-pytest : la mutation « le garde enveloppe autre chose » passait. Le test exige desormais l'egalite stricte du premier jeton suivant -- ; la meme mutation rougit. Meme exigence pour les deux premieres : une garde qui ne rougit pas quand le code est faux ne pinne rien.

Perimetre

Deux fichiers, aucun changement de comportement : les quatre messages emis sont identiques au prefixe pres (verifie ligne a ligne contre HEAD). scripts/ci/xdist_watchdog.py — le prefixe devient une constante nommee, avec la mesure et les deux hypotheses refutees ; scripts/tests/test_xdist_watchdog.py — +3 pins et un commentaire perime corrige (il affirmait que les ##[error] annotent le job, ce qui est vrai, mais sans dire pourquoi — c'est precisement ce qui m'a fait conclure l'inverse). Aucun fichier d'une PR ouverte n'est touche : #17171 garde classify_job_deaths.py.

🤖 Generated with Claude Code

…vigueur

Deux proprietes dont la disparition serait silencieuse, et que rien ne
pinnait : le verdict du garde doit etre une annotation du check-run (toutes
ses lignes, pas seulement la premiere), et le garde doit rester cable autour
de l'invocation pytest de scripts-tests.yml.

Le prefixe d'annotation devient une constante nommee, avec la mesure qui
refute deux hypotheses fausses du meme jour : `##[error]` annote bel et bien
sur le runner GitHub (8 annotations mesurees sur le job 106258931264), donc
basculer vers `::error::` serait un changement sans effet ; et l'organe de
triage n'est pas aveugle a cette mort (le log porte la signature attendue et
aucun `short test summary`, la PR #17171 la reclasse en WORKER_DEATH).

Aucun changement de comportement : les quatre messages emis sont identiques
au prefixe pres.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Sep 21, 2026 •

Copy link
Copy Markdown
Contributor

Path-collision (organ #13359) — résolue

La collision de chemins signalée sur #17241 n'existe plus au passage du 2026-09-22T01:50Z : aucune autre PR ouverte ne partage désormais de chemin de fichier avec elle. Note laissée en place de l'avertissement (retraction non destructive).

@jsboige

jsboige commented Sep 22, 2026

Copy link
Copy Markdown
Owner Author

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2026:CoursIA-3
pr: 17241
head: 4193e32
complete: true
body: read
comments-reviewed: 1
reviews-reviewed: 0
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: bc51d4015eb9971034110f4cc199aabed783c019200981e3d148d18d8d143987
diff-files: 2
diff-additions: 117
diff-deletions: 5
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
[/ADJOINT PREFLIGHT]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants