picker : le garde « repare ton rouge d'abord » ne compare pas a la base — 11 PRs sur 37 accusees pour un echec de main #13545

Le garde « repare ton rouge d'abord » (red_backlog dans scripts/pick_idle_grain.py, mandat user 2026-08-22) a fonctionne exactement comme il est ecrit, et il a eu tort onze fois de suite.

La mesure

Sur les 37 PRs ouvertes le 2026-08-29 a 21h UTC, 11 portent Scripts Tests (CPU) en FAILURE : #13541 #13540 #13539 #13532 #13513 #13499 #13496 #13372 #13062 #13027 #12737 — quatre lanes au moins.

Le log CI de ce check, verbatim (run 33268619208) :

FAILED scripts/translation/tests/test_check_translation_parity.py::test_full_repo_state_passes_parity
  - AssertionError: translation pair count drifted from the declared perimeter:
    found 2, declared 0 (update EXPECTED_PAIR_COUNT knowingly — hold i18n #10038)
= 1 failed, 10036 passed, 59 skipped, 5 xfailed, 1 warning in 291.31s =

Un echec sur 10 036 tests, et il vient de main (#12850 a ajoute 2 *_en.ipynb sans monter la declaration). PR gate etant un agregateur, il tombe derriere — d'ou le check requis en echec : PR gate que le garde lit et attribue a la lane.

Le defaut

Le garde repose sur un predicat implicite : « un check rouge sur ma PR mesure ma PR ». C'est faux des que la base est rouge. Il n'existe aujourd'hui aucune comparaison a la base.

La consequence n'est pas une simple inefficacite. Le garde sort en code 2 — il refuse le tirage tant que le rouge traine. Quand main est rouge, il ne se contente donc pas d'etre inutile : il arrete la flotte entiere, en envoyant chaque lane reparer ce qu'elle n'a pas casse et ne peut pas atteindre. C'est l'inverse exact de son intention, qui etait d'empecher qu'un residu s'accumule faute de reparateur possible : ici le reparateur possible est unique et central, et le garde disperse tout le monde ailleurs.

Mon propre tirage sortait en code 2 pour cette raison, en me listant 5 PRs dont aucune n'avait de defaut propre.

Ce qui manque, et c'est mecanisable

Le predicat absent est « ce rouge existe-t-il aussi sur la base ? ». Il se calcule sans heuristique :

• pour chaque check rouge d'une PR, chercher le meme check (par name) sur main au SHA de base ;
• ou, quand aucun run n'existe sur main pour ce workflow — c'est le cas ici, Scripts Tests ne tourne que sur pull_request —, chercher le meme couple (nom de check, cause) sur une PR etrangere ouverte le meme jour. Deux PRs sans rapport qui echouent sur la meme assertion ne partagent pas un defaut : elles partagent une base.

Sortie attendue : le rouge est impute a la base, pas a la lane. Il n'est plus compte dans le refus de tirage, il est signale une fois, et il devient une tache coordinateur — parce que c'est la seule lane qui peut le reparer.

Cote presentation, un second defaut a corriger au passage : le garde imprime aujourd'hui check requis en echec : PR gate et, deux lignes plus bas, (diagnostic, non bloquant : Scripts Tests (CPU)). Les deux phrases se contredisent — PR gate est rouge parce que Scripts Tests (CPU) l'est. Traiter l'agregateur comme requis et sa cause comme advisory rend le message illisible au moment ou il compte le plus.

Note

C'est la troisieme fois aujourd'hui qu'un rouge de main se presente comme N defauts de PR independants (les deux precedentes : le cliquet de metadonnees ce matin, puis la parite de traduction). Les deux premieres, je l'ai vu apres coup et a la main. La recurrence sur une seule journee est ce qui fait passer le sujet de « vigilance » a « organe » : une regle qui demande de se souvenir de comparer a la base sera oubliee la quatrieme fois.

Contre-mesure manuelle en attendant, valable pour toute lane : avant de croire un « repare ton rouge d'abord », comparer le check rouge de sa PR a celui d'une PR etrangere ouverte le meme jour. Meme check + meme cause = ce n'est pas le sien.

See #13420