CI: l'organe bloquant fast-lane rougit sur "Could not read <sha> / no merge base" sans lire le diff (clone partiel blob:none, course avec main) #15553

Symptôme

L'organe bloquant fastlane de always-on-guards.yml (step « Fast lane (verdicts par garde absorbe) », python scripts/ci/fast_lane.py --shadow) échoue sans rien mesurer :

[fast-lane] impossible de calculer le diff contre origin/main : error: Could not read 8f5211eb23c6848aab9f3676e940cbf592aebeda
fatal: origin/main...HEAD: no merge base
##[error]Process completed with exit code 1.

L'agrégat rend alors Organes bloquants en echec : fastlane, le job sort en exit 1, et le PR gate suit. Une PR dont le contenu est sain est retenue par un organe qui n'a pas pu lire son diff.

Ce qui est mesuré, et ce qui ne l'est pas

Les SHA « illisibles » existent, et ce sont des commits récents de main. C'est le point qui écarte l'hypothèse d'un objet orphelin :

Le runner ne peut donc pas résoudre des commits présents sur l'origine. Le checkout est un clone partiel blobless :

- uses: actions/checkout@v4
  with:
    fetch-depth: 0
    filter: blob:none

Corrélation temporelle relevée sur l'occurrence de #15455 : le run se termine à 03:29:32Z, et main avance à 03:30:06Z (merge de #15484). Les deux SHA illisibles sont des commits de main de la même heure. L'hypothèse de travail est une course entre le git fetch origin "$base_ref" du step et l'avancée de main pendant le run, le fetch promisor du clone partiel échouant à résoudre un commit atteignable seulement depuis la tête plus récente. C'est une hypothèse, pas une conclusion — elle se teste (§ Acceptance).

Rayon de souffle — mesuré, et à ne pas gonfler

Balayage des 60 PRs ouvertes les plus récentes (gh pr list --json number,statusCheckRollup) :

18 PRs sur 60 portent un rouge Always-on. Mais l'échantillon des annotations montre que ce ticket ne les couvre pas toutes, et les confondre serait le défaut à éviter :

Les quatre dernières lignes sont des rouges légitimes appartenant à leur lane : elles ne doivent pas être absorbées dans ce ticket ni servir à en gonfler l'urgence.

Le même Could not read <sha> apparaît 5 fois dans Always-on metadata guards sur le head de #15455 — même classe, organe différent, donc la cause est probablement dans le checkout partagé, pas dans fast_lane.py.

Pourquoi ça compte

fastlane est bloquant. Un organe bloquant qui échoue faute de pouvoir lire son entrée est le pire cas pour une CI : indiscernable, pour qui lit le rollup, d'un vrai défaut de la PR. J'ai moi-même d'abord attribué le rouge de #15455 à une assertion de périmètre de son body — c'était un vrai défaut, corrigé, mais pas celui-là, et perimeter était vert pendant tout ce temps. Le coût de la confusion est une PR retenue et un diagnostic à refaire.

Acceptance

1. Établir la cause plutôt que la supposer : reproduire en relançant un run sur un head inchangé pendant que main avance, ou démontrer que la relance suffit (cause transitoire) — si un simple rerun repasse au vert, la course est établie et le remède porte sur la robustesse du fetch, pas sur fast_lane.py.
2. Rendre l'échec distinguable : un diff illisible ne doit pas produire le même verdict qu'un diff mesuré et fautif. Soit l'organe rend un statut propre (unknown/neutral) avec message explicite, soit il réessaie — mais il ne doit pas rendre « bloquant en échec » sur une entrée qu'il n'a pas lue. Fail-closed reste acceptable, à condition que le message nomme la cause au lecteur du rollup.
3. Robustesse du fetch : évaluer git fetch --filter=blob:none origin +refs/heads/<base>:refs/remotes/origin/<base> explicite, ou un --unshallow/refetch ciblé sur échec de merge-base, plutôt que le git fetch origin "$base_ref" -q actuel.
4. Contrôle négatif : un test qui prouve que l'organe rend bien un verdict bloquant quand le diff est lisible et réellement fautif — sans quoi le remède pourrait rendre l'organe silencieux, ce qui serait pire que le rouge.
5. Re-mesurer le rayon après correctif et relancer nommément les PRs de la ligne « merge-base » du tableau.

Portée

Coordinateur (capacité de digestion). N'appartient à aucune lane de contenu : l'organe est partagé par les cinq workflows absorbés.