ci(sweep-health): l'advisory rougit presque chaque commit de main — course avec le sweep du meme push + DEAD schedule chronique #18292

Constat (mesure du 2026-09-28, 18:00-18:30Z)

Le 28/09, 70 commits ont été mergés sur main. 45 portent une croix rouge.

• 37 ne sont rouges qu'à cause du job PR gate sweep health advisory.
• Au total, ce job compte 47 échecs sur les commits du jour. Les autres rouges sont isolés : une occurrence par nom, et le vert revient au commit suivant.

Vue de la liste des commits, la santé de main a l'air mauvaise, alors que rien de ce qui a été mergé n'est cassé. Une alarme rouge sur presque chaque commit masque en outre les vrais rouges : c'est exactement ce que la docstring de check_scheduler_liveness.py dit vouloir éviter (« A permanently red organ on a chronic condition gets ignored »).

Le parc de runners n'est pas en cause (mesure au même moment) :

• 54 runners en ligne, dont 50 au repos.
• 79 jobs démarrés depuis 14:00Z : attente en file de 3 s en médiane, 90ᵉ centile à 33 s, maximum 44 s.
• Aucun job en attente.

Deux causes distinctes, toutes deux dans .github/workflows/pr-gate-sweep-health-advisory.yml

1. Sonde d'âge du sweep : une course avec le sweep du même push

La jambe push: branches: [main] démarre en même temps que la jambe push de pr-gate-stale-sweep.yml, déclenchée par le même commit. La sonde cherche le dernier sweep terminé en succès (gh run list --workflow pr-gate-stale-sweep.yml --status success --limit 1). Le sweep de ce push tourne encore, donc elle trouve celui du merge précédent.

Chaque fois que deux merges sont espacés de plus de 60 min, le commit reçoit un rouge, alors que le sweep est vivant.

Instance : run 36461754953, au merge de #18023 (17:57:02Z). La sonde a rendu « last successful pr-gate-stale-sweep run is 5263s old ». La réussite trouvée était celle de 16:29:36Z. Le sweep lancé par ce push (run 36461754984, créé à 17:57:02Z) a conclu success juste après.

2. Sonde de cadence : un DEAD chronique imputé à chaque commit

check_scheduler_liveness.py mesure la livraison de l'événement schedule par GitHub, c'est-à-dire l'heure de création des runs, indépendante des runners. Depuis le 09/09 (#15332), GitHub ne livre les crons à 30 et 60 min qu'environ toutes les 4 h 30. Mesure du jour :

• servi 265 min pour 60 déclarées ;
• servi 274 min pour 30 déclarées ;
• servi 263 min pour 30 déclarées.

Les crons quotidiens sont servis à l'heure. Avec DEAD_FACTOR = 4 et DEAD_FLOOR_MIN = 90, un cron à 30 min est DEAD dès 120 min. L'état chronique tombe donc en permanence dans DEAD, et la jambe push recopie ce rouge sur chaque commit de main.

Le travail réel ne souffre pas de cette panne : le sweep est porté par sa propre jambe push, avec une cadence effective de 10 à 50 min, sous le SLA de 60 min (mesures Hermes du 28/09 sur #15332).

Correctif attendu (un seul diff, borné à ce workflow et à ses tests)

1. Sonde d'âge : sur un run push, considérer comme vivant un run pr-gate-stale-sweep.yml dont le head_sha égale github.sha et dont le statut est queued, in_progress ou completed/success. Retomber sur le critère d'âge actuel sinon. Sur schedule et workflow_dispatch, la sonde reste inchangée.
2. Sonde de cadence : sur la jambe push, rendre un DEAD de livraison schedule en avertissement nommé (::warning::, étape verte) au lieu d'un rouge agrégé. Les jambes schedule et workflow_dispatch gardent le rouge, et la ligne dashboard de ai-01 (forme 2 de Apres #12547 le sweep est le seul organe de re-agregation du PR gate — et rien ne dit quand il cesse de battre #12588) garde la mesure. Le verdict de l'organe (OK/LATE/DEAD/UNKNOWN) n'est pas modifié : seul ce que la jambe push imprime sur le commit change.

Hors périmètre : la livraison schedule elle-même, qui relève de GitHub (#15332) ; la hausse des seuils de l'organe ; les runners.

Acceptance

• Contrôle positif : rejouer la situation du run 36461754953 (sweep du même head_sha en cours) donne une sonde d'âge verte.
• Contrôle négatif : aucun run de sweep pour github.sha et dernier succès vieux de plus de 60 min donne toujours un rouge.
• Un DEAD schedule donne un avertissement sur push et reste rouge sur schedule et workflow_dispatch.
• Mesure après merge sur les 20 commits suivants de main : le nombre de commits rouges uniquement à cause de cet advisory tombe de 37 sur 45 (28/09) à 0, hors sweep réellement mort.

Voir #15332 (livraison schedule) et #12588 (forme 2, ligne dashboard).