Le symptôme
scripts/tests/test_check_kernel_suffix_canon.py::TestRenameAwareness::test_rename_to_noncanonical_case_in_adopted_series_reddens est tombé sur le run 34866111429 (PR #15123, job Scripts Tests (CPU), runner linux, Python 3.11.16, git 2.43.0) :
AssertionError: 'case_deviation' not found in ''
= 1 failed, 13544 passed, 91 skipped, 8 xfailed in 228.85s =
Le stdout du garde est vide (zéro octet). C'est la seule information que le test ait laissée.
Le défaut : un plantage et un verdict rouge sont indiscernables
Le test vérifie deux choses, dans cet ordre :
self.assertEqual(r.returncode, 1, "...doit rougir\n" + r.stdout + r.stderr) # l.310
self.assertIn("case_deviation", r.stdout) # l.313 — sans messageUn garde qui plante sort en 1 — exactement le code attendu d'un refus légitime. L'assertion de code retour passe donc par coïncidence, et son message (le seul à porter r.stderr) n'est jamais imprimé. L'assertion suivante échoue contre une chaîne vide, sans diagnostic. Le traceback qui nomme la cause est jeté.
Ce n'est pas propre à ce test : les 22 assertIn(..., r.stdout) du fichier sont sans message, alors que les 14 assertEqual(r.returncode, ...) portent tous r.stdout + r.stderr.
C'est le défaut que ce fichier a été écrit pour attraper, appliqué à lui-même. Son propre docstring :
Se taire a tort. Un garde qui ne denombre pas ce qu'il a regarde rend le meme verdict sur "tout est conforme" et sur "je n'ai rien lu".
Ce qui est mesuré (et ce qui ne l'est pas)
| Mesure |
Résultat |
| Le garde, scénario exact, Linux natif (ext4), git 2.43.0 — la version du runner |
25/25 conformes, case_deviation=1, 749 octets de stdout, stderr vide |
| Le test, Windows, git 2.50.1 |
passe (1 passed in 0.73s) |
scripts-tests.yml sur main, 4 derniers runs |
success (14:59, 14:54, 12:56, 12:41) |
main @ be8e2ce5a 09:55, classé « rouge de base » par plusieurs lanes |
The self-hosted runner lost communication with the server — perte d'infrastructure, pas ce test |
Le garde n'est pas en cause : il imprime toujours au moins son dénominateur (notebooks examines : N), quel que soit son verdict. Un stdout vide n'est donc jamais un verdict de ce garde.
La cause racine reste inconnue, et c'est exactement le problème : l'instrument qui l'aurait nommée a été construit pour la taire.
Coût déjà payé
Trois lanes ont diagnostiqué ce rouge séparément, chacune concluant « rouge imputé à la base, pas réparable par moi » — un verdict correct sur une prémisse fausse (main est vert). Le picker de myia-po-2026:CoursIA-2 l'a reproduit en sortie d'outil.
Correctif
_run_guard est le point de passage unique des 16 tests. L'invariant « ce garde parle toujours » s'y vérifie une fois et couvre tout le fichier — un stdout vide y lève une AssertionError qui imprime le stderr.
Cela ne répare pas la cause racine : cela garantit que sa prochaine occurrence la nomme, au lieu de coûter un cycle à trois agents.
Grain: MED/tooling lane myia-ai-01:CoursIA
Le symptôme
scripts/tests/test_check_kernel_suffix_canon.py::TestRenameAwareness::test_rename_to_noncanonical_case_in_adopted_series_reddensest tombé sur le run34866111429(PR #15123, jobScripts Tests (CPU), runnerlinux, Python 3.11.16, git 2.43.0) :Le
stdoutdu garde est vide (zéro octet). C'est la seule information que le test ait laissée.Le défaut : un plantage et un verdict rouge sont indiscernables
Le test vérifie deux choses, dans cet ordre :
Un garde qui plante sort en 1 — exactement le code attendu d'un refus légitime. L'assertion de code retour passe donc par coïncidence, et son message (le seul à porter
r.stderr) n'est jamais imprimé. L'assertion suivante échoue contre une chaîne vide, sans diagnostic. Le traceback qui nomme la cause est jeté.Ce n'est pas propre à ce test : les 22
assertIn(..., r.stdout)du fichier sont sans message, alors que les 14assertEqual(r.returncode, ...)portent tousr.stdout + r.stderr.C'est le défaut que ce fichier a été écrit pour attraper, appliqué à lui-même. Son propre docstring :
Ce qui est mesuré (et ce qui ne l'est pas)
case_deviation=1, 749 octets de stdout, stderr vide1 passed in 0.73s)scripts-tests.ymlsurmain, 4 derniers runsmain@be8e2ce5a09:55, classé « rouge de base » par plusieurs lanesThe self-hosted runner lost communication with the server— perte d'infrastructure, pas ce testLe garde n'est pas en cause : il imprime toujours au moins son dénominateur (
notebooks examines : N), quel que soit son verdict. Unstdoutvide n'est donc jamais un verdict de ce garde.La cause racine reste inconnue, et c'est exactement le problème : l'instrument qui l'aurait nommée a été construit pour la taire.
Coût déjà payé
Trois lanes ont diagnostiqué ce rouge séparément, chacune concluant « rouge imputé à la base, pas réparable par moi » — un verdict correct sur une prémisse fausse (
mainest vert). Le picker demyia-po-2026:CoursIA-2l'a reproduit en sortie d'outil.Correctif
_run_guardest le point de passage unique des 16 tests. L'invariant « ce garde parle toujours » s'y vérifie une fois et couvre tout le fichier — unstdoutvide y lève uneAssertionErrorqui imprime lestderr.Cela ne répare pas la cause racine : cela garantit que sa prochaine occurrence la nomme, au lieu de coûter un cycle à trois agents.
Grain: MED/tooling lane myia-ai-01:CoursIA