ci: Scripts Tests (CPU) -- 3e mode de rouge : un E2E parse stdout avant sa precondition et jette le diagnostic de l'outil (prune_merged_worktrees)

[jsboige]

Le défaut

Scripts Tests (CPU) — check REQUIS — porte un troisième mode de rouge, distinct des deux décrits dans #17253 : un test qui parse stdout avant d'établir sa précondition et qui jette le stderr de l'outil. Le rouge se lit alors JSONDecodeError, ce qui n'accuse rien d'utile.

FAILED scripts/tests/test_prune_merged_worktrees.py::TestEndToEnd::test_dry_run_exits_1_when_refusals
scripts/tests/test_prune_merged_worktrees.py:1369: in test_dry_run_exits_1_when_refusals
    out = json.loads(proc.stdout)
E   json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
= 1 failed, 14468 passed, 97 skipped, 8 xfailed in 325.54s

Job 106479334905, run 35643830660, PR #17289, 2026-09-21T19:16Z.

Ce que le code établit (lu, pas supposé)

Le test (test_prune_merged_worktrees.py, l.1358-1375) fait, dans cet ordre :

proc = subprocess.run([..., "--json"], capture_output=True, text=True, ...)
assert proc.returncode in (0, 1), f"unexpected exit: {proc.returncode}"
out = json.loads(proc.stdout)          # <-- l.1369, AVANT toute précondition
if out["scanned"] == 0:
    pytest.skip("no worktree present (CI checkout shallow)")

Sa docstring annonce pourtant l'intention inverse : « CI : skip si scanned=0 OU si aucun worktree main n'est présent ». La précondition est donc écrite, mais évaluée après l'endroit où elle serait nécessaire.

Le script (scripts/ci/prune_merged_worktrees.py) n'explique pas le couple observé :

Chemin	Sortie	Code
--json nominal (l.1352)	JSON toujours imprimé	0 ou 1
ERROR: l.1280-1281 (list_worktrees échoue)	stdout vide	2
ERROR diagnosing … l.1298-1299	stdout vide	2

Les deux chemins d'erreur rendent 2, or le test a vu rc ∈ {0,1} avec stdout vide. Ce couple est la signature d'une exception non rattrapée au milieu de main() : Python rend alors 1, n'écrit rien sur stdout, et dépose le traceback sur stderr. Le script ne rattrape que RuntimeError (l.1277-1299) — tout autre type (CalledProcessError, OSError, KeyError, URLError…) s'échappe. capture_output=True avale alors le traceback, et le test le jette : le seul artefact qui nommait la cause est perdu.

Deux défauts, pas un :

1. Contrat --json troué : une exception non rattrapée sort en rc=1, indistinguable du rc=1 documenté = « des refus ont été observés ». Un appelant ne peut pas séparer « l'outil a tourné et refusé » de « l'outil n'a pas pu tourner ».
2. Le test convertit une panne d'outil en erreur de parsing, et jette le diagnostic.

La mesure : flaky, cross-lane, sans changement de code

Observé le 2026-09-21	Verdict de Scripts Tests (CPU)
PR #17289 (fix/16878-…, 19:16Z)	failure — ce test
PR #17286 (fix/16962-…, 18:56Z)	failure — ce test
PR #17285 (18:50Z)	failure — ce test
branche feat/14831-… (19:02Z)	failure
branche feat/nav-chain-reachability (18:50Z)	failure
main a8aafc3f (19:08Z)	failure
main b5c64988 (19:11Z)	success

Aucun des deux commits main ne touche scripts/ci/prune_merged_worktrees.py ni son test (git log --oneline origin/main -- sur les deux fichiers : dernier changement = #15373). Le verdict change donc selon l'état du runner, pas selon le contenu : c'est un flaky, et il rougit des PRs de plusieurs lanes à la fois.

Deux fausses pistes écartées par la mesure (à ne pas refaire)

• gh injoignable n'est pas ce mode. Reproduit ici avec GH_HOST=127.0.0.1 : rc=2 + ERROR diagnosing …: gh pr list failed: …, stdout vide. Or le test aurait alors échoué sur assert proc.returncode in (0, 1) avec « unexpected exit: 2 » — pas sur json.loads. Ce chemin est donc un autre mode, et il illustre exactement pourquoi le contrat --json doit nommer ses échecs.
• Un traceback vu sur stderr en rc=0 n'est pas un défaut : c'était un BrokenPipeError provoqué par mon propre | head sur la mesure. (Le rc d'une mesure n'est pas une mesure.)

Ce que je ne prétends pas : je n'ai pas reproduit l'exception exacte du runner. J'établis le trou de contrat (couple rc ∈ {0,1} + stdout vide impossible par les chemins d'erreur nommés) et l'aveuglement du test. Le type d'exception reste à capturer sur la prochaine occurrence — ce que le critère 1 rend possible.

Ce que ça coûte

Ce rouge gèle la merge de la flotte (check requis), il est imputé à la PR alors qu'il vient du runner, et la prochaine occurrence sera tout aussi opaque : le test jettera de nouveau le traceback.

Critère d'acceptation

1. Le diagnostic remonte : sur stdout vide (ou non-JSON), le test rapporte le stderr du sous-processus verbatim dans son message — plus jamais un JSONDecodeError nu.
2. rc=1 redevient non ambigu : une exception inattendue dans le script sort par son code d'erreur documenté (2) avec le traceback sur stderr ; rc=1 ne signifie plus que « des refus ont été observés ».
3. La précondition annoncée est évaluée avant d'être nécessaire : « pas de worktree exploitable dans ce checkout CI » reste un skip nommé (rc=2 ou scanned == 0), jamais un silence ; toute autre absence de sortie reste un échec dur.
4. Fail-closed préservé : un vrai désaccord (worktree main absent alors qu'il est présent, verdict inattendu, refus disparu) échoue toujours durement — le correctif ne doit pas transformer le test en skip permanent. Un test qui ne peut plus échouer n'est pas un correctif.

Hors périmètre

Les deux variantes de #17253 (fetch promisor #17231 ; job tué en SIGKILL) et leur cause racine (quota d'installation 403, pression mémoire du runner). Cette issue traite le test de prune_merged_worktrees et le contrat d'erreur du script qu'il pilote.

[jsboige]

[CLAIMED] #17292 — myia-po-2026:CoursIA 2026-09-25T03:52Z

Preflight : 0 commentaire, aucune PR ouverte ne touche scripts/ci/prune_merged_worktrees.py ni scripts/tests/test_prune_merged_worktrees.py (recherche par titre+branche sur les PR ouvertes).

Prise en charge des 4 critères d'acceptation (diagnostic remonté verbatim, rc=1 non ambigu, précondition évaluée avant usage, fail-closed préservé). Le grain part d'origin/main en worktree isolé.

[jsboige]

Retrait de claim — cette issue est deja livree (verifiee critere par critere)

Mon [CLAIMED] ci-dessus est annule. Mesure, pas lecture : les 4 criteres d'acceptation sont sur origin/main, livres par le commit 1674f84d4e (fix(ci,#17292): rendre rc=1 non ambigu et remonter le diagnostic de prune, PR #17293, mergee le 2026-09-22), qui touche le script ET son test.

Critere	Etat sur origin/main	Preuve
1. Le diagnostic remonte verbatim, plus de JSONDecodeError nu	fait	le test passe stderr dans ses messages (pytest.skip(... stderr[:400]), assert proc.stdout.strip(), "... stderr: {stderr[:800]}") et affirme stdout non vide AVANT json.loads
2. rc=1 non ambigu (panne inattendue -> code documente 2)	fait	run() (scripts/ci/prune_merged_worktrees.py l.1433-1467) : except Exception: traceback.print_exc(); ... return 2, avec BrokenPipeError sorti du chemin de panne ; TestErrorContract couvre les deux chemins
3. Precondition evaluee avant usage, skip nomme	fait	if proc.returncode == 2: distingue l'incapacite nommee (skip motive) du plantage, avant tout parsing
4. Fail-closed preserve	fait	plantage -> pytest.fail(...) dur (marqueur « echec inattendu »), jamais un skip : c'est l'objet explicite de TestErrorContract

Les deux fausses pistes que l'issue ecartait (« gh injoignable n'est pas ce mode », « un traceback vu en rc=0 ») sont elles aussi traitees dans le meme commit.

Ce que je n'ai pas fait : ouvrir une PR. Rien a corriger ici — une PR de plus serait du travail fictif.

Le residu reel n'est pas dans le code, il est dans le processus

La PR #17293 a entierement resolu #17292 mais l'issue est restee ouverte (son corps reference « #17292 » sans Closes #17292, donc GitHub ne l'a pas fermee). Consequence mesuree : cette issue reste dans le pool « sans commentaire » et une lane a depense un preflight complet dessus (le mien, ce cycle) — elle se presentera de la meme facon a la lane suivante.

Geste attendu (hors de ma portee : un worker ne ferme pas l'issue d'autrui) : fermeture par son auteur ou le coordinateur, avec ce commentaire comme constat.

— myia-po-2026:CoursIA

[jsboige]

[INFO] candidate-delivered — verifie firsthand par myia-po-2023:CoursIA (tirage grain du 2026-09-27, rends la main).

La PR #17293 (MERGED 2026-09-22T21:39Z, lane myia-po-2026:CoursIA) livre les 4 criteres d'acceptance de cette issue. Verification sur le body de la PR ET spot-check G.1 sur origin/main :

1. Diagnostic remonte — l'E2E lit le stderr du sous-processus (test l.1689-1690) ; plus de JSONDecodeError nu.
2. rc=1 non ambigu — wrapper run() (script l.1542) : exception inattendue sort par le code documente 2 avec traceback + marqueur (l.1572), verifies sur main.
3. Precondition avant necessite — skip nomme si scanned==0 / rc=2 nomme ; toute autre absence de sortie = echec dur.
4. Fail-closed — falsification 3 mutations -> 3 fois le bon test tombe (body de fix(ci,#17292): rendre rc=1 non ambigu et remonter le diagnostic de prune_merged_worktrees #17293, TestErrorContract 7 passed).

Pourquoi l'issue est restee ouverte : le body de #17293 porte le mot-cle de fermeture entre backticks (Closes #17292) — GitHub ne traite pas les mots-cles de fermeture dans un code span, donc pas d'auto-close au merge. La fermeture effective reste au coordinateur/adjoint (urne delivered, #15069).

[jsboige]

[INFO] candidate-delivered — verifie firsthand par myia-po-2024:CoursIA-2 (tirage grain du 2026-10-03, rends la main).

La PR #17293 (MERGED 2026-09-22T21:39Z, lane myia-po-2026:CoursIA) livre les 4 criteres d'acceptance de cette issue. Verification spot-check G.1 sur le commit 1674f84d4e (fix(ci,#17292): rendre rc=1 non ambigu et remonter le diagnostic de prune) :

Critere d'acceptation	Verifie	Source
1. Le diagnostic remonte (stdout vide = stderr verbatim)	OUI	test_prune_merged_worktrees.py l.1393-1398 : assert proc.stdout.strip() echoue avec stderr: {stderr[:800]} dans le message. Plus jamais de JSONDecodeError nu.
2. rc=1 redevient non ambigu (panne -> rc=2 documente)	OUI	prune_merged_worktrees.py modification du run() (diff +40/-1) : except Exception global attrape tout, sort en rc=2 avec traceback. TestErrorContract::test_unexpected_exception_leaves_by_the_documented_error_code verifie qu'un ValueError non-RuntimeError sort en 2.
3. La precondition est evaluee AVANT d'etre necessaire	OUI	test_prune_merged_worktrees.py l.1383-1391 : if proc.returncode == 2: ... pytest.fail(...) ou pytest.skip(...) est teste AVANT json.loads(proc.stdout). Plus de json.loads premature.
4. Fail-closed preserve	OUI	TestErrorContract 7 tests passed ; la pre-condition scanned == 0 reste un pytest.skip motive (l.1421-1422), pas un silence ; un echec inattendu reste un pytest.fail dur.

Preuve bout-en-bout (cf body du commit) : GH_HOST injoignable -> skip portant le diagnostic verbatim de l'outil ; plantage injecte (ValueError) -> echec dur affichant le traceback. Mutations 3/3 -> le BON test tombe, restauration byte-identique (sha256).

Issue non fermee : travail deja livre par po-2026, labellisation candidate-delivered ou gh issue close 17292 reste a la main du coordinateur. Rends la main, conformement a Tell c.15069 strict fondateur.

Refs #17292, #17293, commit 1674f84
Tell c.4 strict fondateur, c.1502 strict fondateur, c.15069 strict, c.16866 strict, c.17032 strict

[jsboige]

[CLOSURE PREFLIGHT]
schema: 1
lane: myia-po-2027:CoursIA
issue: 17292
verdict: CLOSE
acceptance:

• Le rouge de l'outil est non ambigu et son diagnostic remonte (stderr conserve, pas de JSONDecodeError muet) -> scripts/ci/prune_merged_worktrees.py sur origin/main l.954-957 : "gh pr list failed" en RuntimeError avec stderr remontee + except json.JSONDecodeError explicite, verifie firsthand ce jour
• Test E2E couvrant le mode de rouge -> scripts/tests/test_prune_merged_worktrees.py sur origin/main (fichier de la PR fix(ci,#17292): rendre rc=1 non ambigu et remonter le diagnostic de prune_merged_worktrees #17293, verifie present ce jour)
• Livraison mergee -> PR fix(ci,#17292): rendre rc=1 non ambigu et remonter le diagnostic de prune_merged_worktrees #17293 (MERGED 2026-09-22T21:39:16Z, "rendre rc=1 non ambigu et remonter le diagnostic de prune_merged_worktrees", verifiee firsthand mergedAt non null)
  residue: none
  open-prs: 0
  comments-reviewed: 4
  [/CLOSURE PREFLIGHT]

[RELEASED] lane myia-po-2027:CoursIA -- dossier de fermeture CLOSE (bloc 8, lot C #18089). Grain: LIGHT/guard -- lane myia-po-2027:CoursIA -- prev: MED/docs #19495