ci(notebook-validation): || true sur check_c2_compliance masque l'erreur réelle et fait crasher le step sur un JSON vide

[jsboige]

Symptôme

Le check validate-notebooks échoue sur certaines PRs avec un crash sans diagnostic :

File "<string>", line 3, in <module>
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

Datapoints : #14777 (run 33979473831, job 101341975582, 05/09 16:59Z), #14790 (run 33981239304, job 101346713713). PRs voisines de la même période passent (#14781, #14772) → intermittent ou corrélé au contenu.

Cause racine (workflow, pas les PRs)

.github/workflows/notebook-validation.yml ligne 80 :

python scripts/notebook_tools/check_c2_compliance.py --json > /tmp/c2_results.json || true

Le || true avale l'erreur réelle du script C.2 (crash, timeout, ou OOM pendant le scan du corpus). Le fichier /tmp/c2_results.json reste alors vide, et le parseur inline de la ligne suivante (json.load) crashe sur Expecting value: line 1 column 1. Résultat : le job fail avec un message qui désigne le mauvais coup (on croit à un notebook JSON invalide alors que tous les notebooks de la PR sont valides — vérifié firsthand sur #14777).

L'erreur réelle du script C.2 est invisible : elle part dans le log avant le || true, sans set -o pipefail ni capture du code retour.

Fix proposé

Dans le step « Check C.2 compliance (execution outputs) » :

python scripts/notebook_tools/check_c2_compliance.py --json > /tmp/c2_results.json
C2_EXIT=$?
if [ $C2_EXIT -ne 0 ] && [ ! -s /tmp/c2_results.json ]; then
  echo "::error::check_c2_compliance.py a échoué (exit $C2_EXIT) sans produire de JSON — voir stderr ci-dessus"
  exit 1
fi

Fails loud avec la vraie cause si le script crashe ; le caractère advisory du check C.2 sur les PRs (ligne 89) est préservé quand le JSON est produit.

Question ouverte

Pourquoi check_c2_compliance.py échoue-t-il sur ces runs-là ? Les deux jobs fautifs durent 12m+ (vs ~1m pour les verts) — piste : timeout/OOM du scan corpus sur les PRs à gros diff (#14790 = 63 fichiers). À reproduire localement : python scripts/notebook_tools/check_c2_compliance.py --json sur un checkout de #14790.

Note : le même échec bloque aussi PR gate (agrégat) sur #14777 (avec Gitleaks à 10m00s pile = second timeout suspect, même run) et #14790.

[jsboige]

[CLAIMED] lane myia-po-2026:CoursIA -- fix || true du step C.2 (fail loud, advisory préservé) + diagnostic de la question ouverte (crash check_c2_compliance sur gros diffs, reproduction locale #14790)
Grain: MED/tooling -- lane myia-po-2026:CoursIA -- prev: MED/guard #14781

[jsboige]

[RELEASED] lane myia-po-2026:CoursIA — PR #14815

Fix : capture C2_EXIT + fail loud si le scanner exit ≠ 0 sans JSON (crash), fail loud avec tête du fichier si non-JSON/tronqué (couvre le cas réel), garde faux-vert au step nbformat (fail si find voit 0 carnet). Advisory préservé : exit 1 AVEC JSON valide reste ::warning::. Harnais de rejeu local 6/6.

Question ouverte — résolue par forensique (logs du job fautif 101341975582, runner myia-ai-01-wsl-4) : le scanner n'a PAS échoué. Le checkout du runner ephemeral n'a écrit que 7366 des 9060 fichiers du merge ref f12fc8bb8 (vérifié git ls-tree -r) — tous les .ipynb manquaient : step nbformat « validated » en 0,13 s (zéro itération, faux vert), scanner sorti No notebooks to check. (exit 0), parseur inline crashe sur ce texte. Intermittence confirmée : les re-runs des deux runs fautifs sont verts (#14777 attempt 2 : 4m3s, warning advisory normal).

Piste OOM/timeout de l'issue réfutée empiriquement : repro locale sur checkout complet de #14790 → 1092 carnets en 29,2 s, RSS max 110 MB (plus gros carnet 42,3 MB inclus dans le scan). Le « 12m+ » = jobs Gitleaks/PR-gate du même push, pas le job notebook-validation (34 s).

Résiduel : la racine côté runner (checkout incomplet après kill, cancel-in-progress actif) = sujet infra, désormais visible grâce aux gardes au lieu de masquée.