organ(prevalidation): une tete sans run du PR gate passe 'latest-wins-green' par vacuite

Constat

Le gate d'entrée scripts/check_adjoint_prevalidation.py accepte une affirmation checks: latest-wins-green sur une tête qui ne porte aucun run du PR gate. check_claim_contradictions ne contredit que les checks présents : si la tête n'a pas de check-run PR gate, rien ne contredit la claim et le dossier passe.

Reproduction sur la fonction, à main du 30/09 :

only CodeQL      -> []
no runs at all   -> []
PR gate red      -> ["checks claim 'latest-wins-green' is contradicted by live check 'PR gate' (failure)"]

Une tête sans aucun run vaut donc une tête toute verte.

Instances du 30/09

#18527 et #18500 : leur tête (fusion de main poussée à 04:30Z) ne portait que les 5 jambes CodeQL de l'analyse « dynamic ». Aucun workflow pull_request n'avait été déclenché, donc pas de PR gate. Leurs dossiers ont été signalés READY par vacuité ; la plateforme les tenait en BLOCKED (check requis absent).

Le défaut est borné : ni ai-01 ni merge_ready.py ne peuvent merger, puisque la plateforme exige le PR gate et que merge_ready exige mergeable_state: clean. Son coût est ailleurs : un faux READY consomme une lecture de coordinateur, et masque le vrai problème (une CI qui n'a jamais tourné). La CI a été relancée à la main par fermeture et réouverture.

Correction proposée

Une constante des checks dont la présence est exigée, au minimum PR gate, le check requis par la protection de main. La protection de branche n'est pas lisible sans droit admin (404 sous myia-ai-01, cf. docs(ci,#9819): rollout Step 2 -- flip required_status_checks gated user #9991) : la liste s'écrit donc dans l'organe.
Pour une claim latest-wins-green, un check exigé absent de la tête, ou sans aucun run terminé, est une contradiction nommée ('PR gate' absent de la tête), au même titre qu'un check rouge.
Tests : les trois cas ci-dessus, avec en plus un PR gate en cours sans run terminé antérieur.

Hors périmètre

Pourquoi la fusion de 04:30Z n'a déclenché aucun workflow. Aucun organe de balayage n'a tourné à cette minute, et deux PRs ont été mises à jour à 20 s d'intervalle. La cause reste à établir ; l'organe doit de toute façon tenir face à une tête sans CI, quelle qu'en soit la cause.

[CLAIMED] lane myia-po-2023:CoursIA-2 -- organ prevalidation vacuity fix : constante REQUIRED_CHECKS=['PR gate'] + tests 3 cas + tests PR gate in-flight sans run termine anterieur -- paths: scripts/check_adjoint_prevalidation.py, scripts/tests/

Grain: LIGHT/guard -- lane myia-po-2023:CoursIA-2 -- prev: LIGHT/hygiene #18562

[INFO c.955] Fix livre sur PR #18648 (myia-po-2023:CoursIA-2)

Geste

scripts/check_adjoint_prevalidation.py : ajout constante REQUIRED_CHECKS = ["PR gate"] + contradiction nommee quand un check exige est absent de latest_wins_check_runs(check_runs). 3 nouveaux tests + 1 test mis a jour (le test test_skipped_and_neutral_conclusions_are_not_red etait par construction un cas de vacuite verte, il ajoute maintenant un run PR gate success).

Verification

python -m pytest scripts/tests/test_check_adjoint_prevalidation.py : 108 passed.

PR #18648 fix(prevalidation,#18579) -- lane-unique fix/18579-prevalidation-vacuity, force-push pas necessaire, attente tierce review puis merge ai-01.

Grain: LIGHT/guard -- lane myia-po-2023:CoursIA-2 -- prev: LIGHT/hygiene #18562
See #18648

fix(prevalidation,#18579): an absent PR gate run contradicts latest-w…

Etat mesure au 2026-10-08T00:50Z — recidive, et le fix documente (close/reopen) ne guerit plus.

Ce qui est mesure

Sur les branches feature/komlos-k24-pullback (PR #19084) et feature/komlos-k25-mean (PR #19087), dans la nuit du 07/10 au 08/10 :

Canal	Geste	Resultat
push `synchronize`	push du merge commit `588b924768` (k24) puis `68b562756b` (k25)	0 run cree sur les deux branches
`reopened`	close + reopen de #19084 (le fix documente du 30/09)	0 run cree
`edited`	`gh pr edit 19084 --body-file` (body reellement modifie, +bloc d'etat)	0 run cree

Verification : gh api repos/jsboige/CoursIA/commits/<head>/check-runs rend 0 check-run aux têtes poussees, pour un workflow always-on-guards.yml qui ecoute pull_request: [opened, synchronize, edited, reopened] sans filtre de chemins — un push sur ces branches DOIT creer un run.

Pourquoi ce n'est pas un problemas de ces PRs seules

Pendant la meme fenetre, les evenements fonctionnent ailleurs dans le depot : runs crees a 00:35Z (push fix/17369), a 00:42-00:45Z (issue_comment / workflow_run). Le probleme semble cible sur ces branches / ce groupe d'evenements, pas repo-wide.

Consequence operationnelle

Les 4 PRs restantes de ma file de reparation CI (feat(lean,#17845): brique k2.6a -- pont de niveau liftUp/pushUp (embedding produit vers Fin (d+1)) #19089, feat(lean,#17845): brique k2.6 — sum_smul_inl générique (assemblage SignedSums + jumeau _en) #19425, feat(lean,#17845): brique k2.6b -- la scission sous contention dans la dimension agrandie (LiftSplit + jumeau _en) #19445, feat(lean,#17845): brique k2.6c -- l'assemblage final (Lemme 1.4, SignedSums + jumeau _en) #19464) sont gelees : sans PR gate vert a la tete exacte, ni l'organe de prevalidation ni le merge-gate ne peuvent passer (latest-wins-green par vacuite = dossier non attestable).
GitHub reste aussi bloque sur le recompute de mergeabilite : feat(lean,#17845): brique k2.4 -- pas complet de pullback (toRealProd + caracterisations de support + pullback) #19084 affiche CONFLICTING/DIRTY alors que git diff 588b924768..origin/main est vide (la branche contient main en integralite) — coherent avec une livraison d'evenements cassee.

Demande

Le diagnostic « hors perimetre » du 30/09 tenait tant que close/reopen guerissait. Ce n'est plus le cas : la recidive est mesuree et le workaround documente est mort. Il faut soit un canal de re-declenchement fiable (workflow_dispatch avec payload PR ?), soit une remontee vers le support GitHub. Toute piste bienvenue — de mon cote je continue a documenter chaque instance ici.

Bornage supplementaire (01:07Z) : un push sur une branche neuve (fix/wip-salvage-29sep-reexec, PR #19839, commit 084bede) vient de declencher tous les workflows normalement — 52 check-runs a la tete, runs queued dans la seconde. La livraison d'evenements est donc saine au repo-wide pour les nouvelles branches a cet instant ; la panne est specifique aux branches/PRs komlos k24-k25 (etat interne de ces PRs ? branches en quarantaine apres les echecs du 30/09 ?). Cela oriente le diagnostic vers l'etat des objets PR/branche concernes plutot que vers l'infrastructure d'evenements elle-meme.

ci: rejouer les gardes -- aucun evenement livre a 6245796 (#18579)

feat(lean,#17845): brique k2.4 -- pas complet de pullback (toRealProd…

Fix(prevalidation,#20078): un dossier BLOCKED pour `checks` seul est …

Navigation Menu

Repository navigation

organ(prevalidation): une tete sans run du PR gate passe 'latest-wins-green' par vacuite #18579

Constat

Instances du 30/09

Correction proposée

Hors périmètre

Geste

Verification

Ce qui est mesure

Pourquoi ce n'est pas un problemas de ces PRs seules

Consequence operationnelle

Demande

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

organ(prevalidation): une tete sans run du PR gate passe 'latest-wins-green' par vacuite #18579

Description

Constat

Instances du 30/09

Correction proposée

Hors périmètre

Activity

jsboige commented on Oct 1, 2026

jsboige commented on Oct 1, 2026

Geste

Verification

jsboige commented on Oct 8, 2026

Ce qui est mesure

Pourquoi ce n'est pas un problemas de ces PRs seules

Consequence operationnelle

Demande

jsboige commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions