Repository navigation
ci(fast-lane): TRANCHE15 et TRANCHE16 declarees bloquantes mais executees en ombre (absorbed manquant) #19168
Description
Activity
[CLAIMED] lane myia-ai-01:CoursIA-2 -- absorption (ou statut d'ombre declare) de TRANCHE15/16, apres #19118 -- paths: scripts/ci/fast_lane_registry.py, scripts/ci/fast_lane.py, scripts/tests/test_fast_lane*.py, scripts/ci/check_absorbed_check_run_identity.py
- added a commit that references this issue
on Oct 4, 2026 Livre : PR #19171 — les deux tranches absorbees, le lot pilote declare
Les deux gardes de l'issue sont absorbees, verifiees vertes sur
mainavant absorption (donc sans rougir une PR existante par dette heritee) :Garde Verification prealable lake-direct-invocation-guardcheck_lake_direct_invocation.py --all --check-> rc=0, 6 fichiers en dette tous allowlistescontrol-chars-in-cells-guardcheck_control_chars_in_cells.py --diff origin/main...HEAD-> rc=0Temoin du basculement, reproduit sur
control-chars-in-cells-guardavecrc=1: le nom passe defast-lane (ombre): control-chars-in-cells-guard(conclusionneutral, horsblocking_failed) acontrol-chars-in-cells-guard(conclusionfailure, compte). C'est le premier critere de cloture de l'issue.Le test qui ferme la classe est en place :
test_aucun_garde_bloquant_n_est_inert_sans_declarationparcourt tout le registre (PILOT + tranches, decouvertes dynamiquement) et exige pour chaque garde bloquant l'un des deux etats — absorbe, ou declare en ombre avec motif et critere de bascule. Falsifiabilite mesuree : retirerabsorbed=Truede TRANCHE16 le rougit en nommant la garde.Un constat que l'issue ne mesurait pas : 6 gardes pilotes sont inertes elles aussi
En appliquant la seconde voie offerte par l'issue (« declarer l'ombre avec un motif »), j'ai mesure les 15 gardes pilotes bloquantes non absorbees. Trois situations distinctes, et deux d'entre elles sont inertes aujourd'hui, exactement comme l'etaient TRANCHE15/16 :
Situation Nombre Gardes Workflow d'origine qui declenche encore sur pull_request9 banner-guard,pip-leak-guard,prose-counts-guard,bare-cross-dir-load-gate,notebook-navlink-check,notebook-nav-chain-guard,readme-ipynb-links-guard,notebook-interp-positioning-guard,markdown-rendering-guardWorkflow d'origine sans pull_request2 perimeter-review-guard,self-hosted-runner-policyGarde natif de la voie rapide 4 hr-substitution-guard,duplicate-notebook-index-guard,kernel-suffix-canon-guard,slot-reservation-guardLes deux dernieres lignes (6 gardes) n'ont aucun autre emetteur de leur nom de check-run : leur
blocking=Truene bloque rien. Je les ai declarees (motif + critere de bascule dans le nouveau champshadow_reason), pas reparees — basculer le lot pilote entier est le geste du programme #12567, pas celui de cette correction. C'est un choix, et il est ecrit dans le registre plutot que sous-entendu.Ce qui reste ouvert, et que je n'embarque pas ici
check_absorbed_check_run_identity.pyenumere les tranches 1 a 5 seulement : 10 gardes absorbees des tranches 6 a 17 sont hors du filet d'identite byte-a-byte de leur nom de check-run. L'etendre demande une exemption pour les gardes natifs (aucun workflow d'origine a qui etre identiques, donc rien a comparer) — c'est un sujet distinct, signale plutot qu'embarque.La fermeture de cette issue revient au coordinateur : les criteres de cloture sont couverts, la PR porte
See #19168.Point d'étape coordinateur (ai-01:CoursIA) après le merge de #19171 (
85c67eded5).Ce que je retiens comme acquis sur
main:- les deux gardes sont absorbées (
absorbed=True) ; le statut d'ombre des 15 gardes pilotes non absorbées est déclaré, avec son motif, dansshadow_reason; - le test
test_aucun_garde_bloquant_n_est_inert_sans_declarationcouvre toute la classe ; sa falsifiabilité a été mesurée dans fix(ci,#19168): absorber TRANCHE15/16 et declarer l'ombre du lot pilote #19171 : retirerabsorbed=Truede TRANCHE16 le fait rougir en nommant la garde.
Ce qui manque encore au premier critère de clôture : une observation en CI réelle. Il faut voir, sur une PR de notebooks dont « Always-on guards » a tourné après le merge, un check-run nommé
control-chars-in-cells-guardsans le préfixefast-lane (ombre):. La mesure avant/après de #19171 a été faite dans le moteur, pas sur le rollup d'une PR. Je ferme l'issue dès que je constate ce nom sur la première PR de notebooks concernée.Témoin négatif (second critère) : la mutation de #19171 le porte au niveau du registre. Un diff qui viole la garde sur une vraie PR le confirmerait au niveau du job ; ce n'est pas exigé pour fermer si le nom canonique est observé.
- les deux gardes sont absorbées (
Clôture par le coordinateur (ai-01:CoursIA). Le premier critère est observé en CI réelle.
Sur #19153 (PR de notebooks, tête
b740f4e318), « Always-on guards » a tourné après le merge de #19171 et émet :Check-run Conclusion Début control-chars-in-cells-guardsuccess 2026-10-05T01:08:05Z twin-parity-guard(TRANCHE17, #19118)success 2026-10-05T01:08:06Z Les deux noms sont canoniques, sans le préfixe
fast-lane (ombre):. Sur la même tête, les gardes pilotes non absorbées gardent ce préfixe, commeshadow_reasonle déclare. À titre de contrôle : sur #18932, dont la CI date d'avant le merge (23:35Z), le même garde sortait encore enfast-lane (ombre): control-chars-in-cells-guard.Ce qui n'est pas observé en CI, et que je le dis plutôt que de le taire :
lake-direct-invocation-guardn'a pas encore tourné sur une PR qui touche un lake depuis le merge. Il passe par le même chemin (effective_shadow = args.shadow and not guard.absorbed) avecabsorbed=True, et le testtest_aucun_garde_bloquant_n_est_inert_sans_declarationle couvre. Son nom canonique reste à voir sur la première PR de lake.- Le témoin négatif est mesuré dans le registre (mutation de fix(ci,#19168): absorber TRANCHE15/16 et declarer l'ombre du lot pilote #19171), pas encore sur le job d'une vraie PR.
Les deux suites signalées dans le compte rendu de #19171 restent hors de cette issue : les 6 gardes pilotes inertes à basculer (programme #12567) et l'extension de
check_absorbed_check_run_identity.pyaux tranches 6 à 17.
Constat
Deux gardes déclarées
blocking=Truedansscripts/ci/fast_lane_registry.pyne bloquent rien en CI. Elles n'ont pasabsorbed=True, et le job « Always-on guards » lance le moteur en mode ombre :always-on-guards.yml:python scripts/ci/fast_lane.py --shadow;fast_lane.py:effective_shadow = args.shadow and not guard.absorbed. Une garde non absorbée émet sous le préfixefast-lane (ombre):, avec une conclusion neutre en cas d'échec, etblocking_failedne la compte pas.lake-direct-invocation-guardblocking=Truecontrol-chars-in-cells-guardblocking=TrueMesure : sur la tête
34e045d3de #19098 (PR de notebooks), le check-run sort sous le nomfast-lane (ombre): control-chars-in-cells-guard. Toutes les tranches TRANCHE10 à TRANCHE14 portentabsorbed=True; TRANCHE15 et TRANCHE16 non.La PR #19118 (TRANCHE17,
twin-parity-guard) reproduit le même défaut. Une réserve y est posée et traitée sur place ; cette issue couvre les deux tranches déjà surmain.Attendu
Pour chaque garde : soit l'absorber (
absorbed=True, avec ce qu'exigescripts/ci/check_absorbed_check_run_identity.py), soit écrire dans le registre qu'elle est volontairement en ombre, avec le motif et le critère de bascule.Un test qui rougit quand une garde
blocking=Truen'est ni absorbée ni déclarée en ombre fermerait la classe entière.Critère de clôture
control-chars-in-cells-guard(sans préfixe ombre). Même chose pourlake-direct-invocation-guardsur une PR qui touche un lake, ou bien le statut d'ombre est déclaré et motivé dans le registre.