ci(pr-gate-stale-sweep): un "PR gate" absent (run annulé avant rendu) laisse la PR BLOCKED à vie — le sweep ne peut pas voir la classe #21463

Constat (mesure du 2026-10-19, lane myia-po-2027:CoursIA-2)

Cinq PRs de ma lane sont BLOCKED sans aucun rouge et ne peuvent jamais passer CLEAN : le check-run PR gate — un check requis sur main — n'a jamais été posté sur leur tête. GitHub compte un check requis qui n'a jamais commencé comme pending à jamais ; la PR est donc morte sans avoir jamais rougi.

La signature mesurée

Instrument de détection (l'absence, pas la couleur) :

gh api repos/jsboige/CoursIA/commits/<head>/check-runs \
  --jq '[.check_runs[]|select(.name=="PR gate")]|length'
# 30 check-runs verts, PR gate = 0  ->  PR morte en silence

Contrôle négatif : les runs success des mêmes branches ont bien leur check-run PR gate (ex. 38957904962 sur b413fcde1706, 38820474460 → failure sur 6339ce39fb60). La signature n'est donc pas « PR ancienne » : c'est « run annulé sans avoir rendu son verdict ».

Contrôle sur l'instrument : scripts/check_run_state.py --pr N --json ne voit pas cette classe. Il lit les check-runs présents ; un check-run absent n'entre pas dans latest_reds ni dans residual_reds. Le vert affiché est un faux vert — c'est ce qui rend la classe si discrète.

Les deux causes, distinctes

1. L'annulation — .github/workflows/pr-gate.yml porte concurrency: pr-gate-<numéro de PR> avec cancel-in-progress: true. Un run peut être annulé avant que son job n'ait posté le check-run : le verdict n'est alors jamais rendu.

2. L'aveuglement du sweep — .github/workflows/pr-gate-stale-sweep.yml, l.413 :

   if printf '%s' "$BODY" | grep -q '"name":"PR gate"'; then
     WFMAP=$(gh api "repos/$REPO/actions/runs?head_sha=$SHA&per_page=100" ...)
   else
     WFMAP=''
   fi

   La carte des executions n'est récupérée que si le check-run PR gate est déjà présent sur la tête. Or c'est précisément son absence qui définit la classe : le sweep ne voit donc jamais le run annulé qu'il devrait relancer. Le filtre exige l'artefact dont l'absence est le défaut.

   Le commentaire l.405-412 justifie ce filtre par un argument de coût (11 min d'étape 3 sur ~100 PRs × 1-2 appels REST : le WFMAP serait « du travail mort » pour la population non-candidate). C'est un bon argument — mais il s'applique à la population qui a un gate ; la population sans gate est précisément la cible, et elle est étroite (sur les 40 PRs ouvertes les plus récentes, mesurées ce jour : 0 PR BLOCKED sans PR gate).

Le geste qui marche, et qui ne casse rien

gh run rerun <run_id>        # le run ENTIER du pr-gate.yml, sur le head SHA

Le rerun rejoue le payload d'origine et re-publie le check-run PR gate sur la tête exacte. Vérifié ce jour sur les 5 instances : les 5 reruns passent en attempt=2 (in_progress / queued) sur le bon SHA. Contrainte : l'exécution à relancer doit être relançable (c'est le point sur lequel bute #19050 — là, c'est un run pr-gate.yml, donc lançable).

Ce n'est pas un push : un push muet ne rend aucun verdict et re-arme le plancher DWELL ; le rerun ne touche à rien et ne re-arme rien. Même famille de geste que le re-roll de job déjà documenté dans git-workflow.md, mais au niveau du run quand c'est le run qui est cancelled et non un job.

Ce qu'il faut décider

1. Le sweep doit voir la classe « gate absent » — sans cela, elle reste invisible au seul organe qui répare les gates périmés, et les PRs meurent en silence (durée mesurée : run annulé le 18/10 13:31Z, PR encore morte le 19/10 20:3xZ, soit 10 h).
2. Correctif minimal proposé : étendre la condition l.413 de grep -q '"name":"PR gate"' à grep -q '"name":"PR gate"' || [état de la PR = BLOCKED] — le WFMAP n'est alors demandé que pour la population BLOCKED sans gate, dont la taille mesurée est nulle sur les 40 PRs les plus récentes (donc un coût marginal, pas un coût de pool).
3. Trinitaire à trancher : qui répare une PR dont le gate n'a jamais été rendu — le sweep (relance du run), ou la lane (relance manuelle, geste documenté ci-dessus) ? Les deux existent aujourd'hui sans qu'aucun organe ne le dise.
4. À instrumenter : l'absence de PR gate sur une PR BLOCKED est aujourd'hui invisible de tout organe de mesure — check_run_state.py la voit comme un vert. C'est le même angle mort que celui décrit dans pr-gate-stale-sweep : un PR gate rouge rattache a une execution CodeQL dynamique ne peut pas etre relance #19050 (un organe qui ne voit pas sa propre classe).

Parent

Sans parent : les parents naturels de cette chaîne (#12728, #10433, #10435) sont clos et cette classe n'en est pas un sous-ensemble — elle est **voisine** de #19050 (même swept, mécanisme distinct : là une jambe rouge dans une suite non relançable, ici **aucune jambe** parce que le run a été annulé avant rendu).

Liens

• pr-gate-stale-sweep : un PR gate rouge rattache a une execution CodeQL dynamique ne peut pas etre relance #19050 — même famille, autre sous-cas (jambe rouge non relançable)
• fix(guard,#11155): le ratchet papermill juge la branche, pas son retard #11532 — même famille, exécution relançable
• picker: un PR gate rouge par constituant cancelled est assigne comme grain reparable — 3e surface de #15726 #15763 — PR gate annulé vu comme grain réparable par le picker (3ᵉ surface)
• PR gate: une conclusion en echec peut rendre output.title = null -- le log parle, l'API non #15825 — output.title = null sur une conclusion en échec (rejeu inerte)
• git-workflow.md — le re-roll gratuit qui ne re-arme pas DWELL