Repository navigation
pick_idle_grain --belt : derniere visite tronquee a 14 jours, et --json qui rend deux objets #18866
Description
Activity
[CLAIMED] lane myia-po-2024:CoursIA-2 -- paths: scripts/pick_idle_grain.py, scripts/series_saturation.py, scripts/tests/test_belt, scripts/tests/test_saturation -- deux corrections bornees : (1) elargir la fenetre de last_delivery_per_issue en mode --belt (les livraisons au-dela de 14 jours sont oubliees, cf. mesure #1203), (2) --json rend un seul document JSON (le garde rouge et le tapis fusionnes en un seul objet). Issue de suivi identifiee, scope delimite.
[INFO] delivered -- PR #18869 livree (#18869).
Deux corrections en une PR bornee sur
origin/feature/18832-picker-belt-mode:- Fenetre
last_deliveryetendue a 90 j en mode --belt (constanteBELT_WINDOW_DAYSdansscripts/series_saturation.py). - Sortie --json en UN seul document (cle
repairfusionnee dans le doc du tapis quand un garde rouge/WIP s'est declenche).
Tests : 3 ajoutes dans
test_pick_idle_grain_belt.py; 255 passes surpick_idle_grain* + series_saturation, 0 regression.Genere par lane myia-po-2024:CoursIA-2.
- Fenetre
- added a commit that references this issue
on Oct 2, 2026 - added a commit that references this issue
on Oct 5, 2026 - added a commit that references this issue
on Oct 5, 2026 - added a commit that references this issue
on Oct 6, 2026
Constat
J'ai testé en live le mode
--beltde #18836 à la tête14f5856ca6, et deux écarts restent hors de cette PR.1. La dernière visite n'est lue que sur 14 jours
last_delivery_per_issueest appelé avecdays=DEFAULT_WINDOW_DAYS, qui vaut 14 (scripts/series_saturation.py:51). Une issue servie il y a plus de 14 jours n'a donc pas delast_delivery_stamp.belt_sort_keyla classe alors à sa date de création, comme si elle n'avait jamais été servie.Exemple mesuré : #1203 sort en tête du tapis, avec le libellé
[NEVER]et 139 jours depuis la dernière livraison. Pourtant, des PRs mergées la citent : #15404 le 2026-09-09, #14984 et #13886 avant.Conséquence : une vieille issue servie il y a 15 à 30 jours passe devant une issue créée en juin ou en août que personne n'a jamais servie. La règle de #18832 veut l'inverse. La file trie sur la dernière visite réelle, sinon sur la date de création.
Dans le régime visé (environ 100 grains par jour pour environ 500 issues), toute issue est revisitée en moins de 14 jours et l'écart disparaît. Mais il fausse l'ordre de démarrage, et tout régime plus lent. Il fausse aussi l'affichage : la colonne indique
[NEVER]pour des issues déjà servies.Attendu : en mode
--belt, la dernière visite couvre tout l'historique des PRs mergées, ou au moins une fenêtre nettement plus longue qu'un tour complet de la file. Le libellé[NEVER]ne doit apparaître que pour une issue qu'aucune PR mergée ne cite.Contrôle : après le correctif,
--belt --jsonne doit plus classer #1203 en tête. Sonlast_delivery_stampdoit valoir au moins2026-09-09.2.
--jsonpeut rendre deux objets à la suitePour une lane qui a des PRs rouges, la commande
--belt --lane myia-po-2025:CoursIA --jsonimprime d'abord l'objet du garde rouge (lane,mode,assignment,red…), puis l'objet du tapis.json.loadéchoue avecExtra data. Un consommateur doit donc découper la sortie à la main.Attendu : un seul document JSON sur la sortie, par exemple avec le garde rouge comme clé de l'objet du tapis.
Origine
Ces deux points ont été relevés pendant la levée de ma réserve sur #18836. Ils ne bloquent pas ce merge : ils sont reportés ici sciemment. Parent : #18832.