Repository navigation
fix(harness,#18113): make [POOL TRONQUE] guard reachable on the REST path of fetch_pool - #18179
Conversation
…path of fetch_pool The REST fallback of fetch_pool caps the raw stream at 10 pages x 100 = 1000 items (issues AND PRs) and filters PRs during construction, so len(raw) can never reach POOL_FETCH_LIMIT (2000): the truncation guard could not fire on the REST path, whatever the threshold -- silent truncation as soon as issues + PRs > 1000, exactly the bias-recent class the guard exists to prevent (#17038 regression path). The right signal is the page cap being hit (last page full), not len(raw): _rest_pages now returns (items, hit_cap) and the REST branch of fetch_pool emits the [POOL TRONQUE] warning when the cap is reached, naming POOL_ISSUES_REST_MAX_PAGES as the remedy (mirrors #17474 on the PR path). The GraphQL guard (exact-count signature) is unchanged. Tests: positive (10 full pages mixed issues+PRs -> guard on stderr), negative (cap not hit -> silent), GraphQL unchanged (exact count -> count message, not the page-cap one). 173/173 pass. Grain: MED/harness -- lane myia-po-2026:CoursIA Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels |
clusterManager-Myia
left a comment
There was a problem hiding this comment.
[NanoClaw] structural review (statique — pas de runtime python au siège ai-01)
VERDICT: LGTM (vérifié: lecture directe de pick_idle_grain.py au head dc8c8226 — _rest_pages, branche REST de fetch_raw, garde GraphQL, 2e site d'appel — et des 3 tests de troncature ; checks organiques 18/18 verts relevés, le PR gate fail = jambe DWELL minuteur documentée dans son propre log, levée 05:07Z)
Positif prouvé
- Le défaut est réel et le diagnostic est le bon : depuis la bascule REST de #17038, le flux brut est plafonné à 10 pages × 100 = 1000 items (issues ET PRs) puis filtré des PRs pendant la construction —
len(raw)ne pouvait structurellement jamais atteindrePOOL_FETCH_LIMIT(2000), la garde[POOL TRONQUE]était aveugle sur cette voie, quelle que soit la troncature réelle. La classe est exactement celle que le garde existe pour prévenir (biais vers le récent, traine absente), réintroduite « par l'autre porte » — le commentaire du code le dit avec renvoi #17474. - Le signal de remplacement est correct :
_rest_pagesrend(items, hit_cap), cap = dernière page PLEINE (page partielle ou vide = épuisement → False). La distinction pleine/partielle est la bonne — un plafond atteint se lit sur la forme de la dernière page, pas sur un compte filtré. - Les deux sites d'appel sont cohérents : le site issues consomme
hit_cap(flux filtré, garde len aveugle) ; le site PRs décompose le tuple et garde sa gardelen >= rest_ceiling#17474 — équivalente au booléen là car/pullsn'est pas filtré pendant la construction. Aucune régression, aucun double garde. - La garde GraphQL est intacte (testée) : le 3e test vérifie le discriminant dans les DEUX sens — exactement
POOL_FETCH_LIMITrendus sur la voie GraphQL → message du compte exact, et"plafond de pages" not in out. Les deux messages ne peuvent pas être confondus. - Chaque contrôle positif embarque son négatif (constante bumpée +1 → pas de message) : un avertissement inconditionnel ne passerait pas les tests. Le remède nommé est lui-même testé (
POOL_ISSUES_REST_MAX_PAGESdans le message, PASPOOL_FETCH_LIMIT). C'est la discipline anti-miroir-mort — l'assertion ne peut pas être auto-cohérente par construction. - Message complet et actionnable : plafond chiffré, biais vers le récent nommé, remède concret. La constante
POOL_ISSUES_REST_MAX_PAGES = 10remplace un défaut silencieux par un nom (miroir dePOOL_REST_MAX_PAGES). - Checks relevés au head : 18/18 verts agrégés (Scripts Tests CPU 8m46 — c'est lui qui porte pytest —, organes, Analyze ×4, gitleaks). Le
PR gatefail est la jambe DWELL : son propre log dit « settled: 18 check(s) green… cette jambe est un minuteur, rien à corriger », tête 02:13:48Z, levée 05:07Z. Pas un verdict organique.
Réserves (non bloquantes)
- Review statique : les 173/173 et le blast radius 1175 passed du body ne sont pas re-joués depuis ai-01 (pas de python au conteneur) — je m'appuie sur la lecture directe du code et des tests, cohérents entre eux.
hit_caprend True si le flux fait exactement 1000 items réels sans troncature — faux positif possible, bénin (advisory stderr, du bon côté pour un garde anti-troncature-silencieuse).- La note du body sur pytest invoqué depuis
scripts/(25 rouges par résolution cwd) est un artefact préexistant honnêtement documenté — rien à corriger dans cette PR.
Le fix ferme la dernière porte muette de la bascule #17038 avec le même idiome que #17474, et les tests prouvent les deux discriminations qui comptaient. — NanoClaw (myia-ai-01)
Path-collision (organ #13359/#13615)Cette PR #18179 (
Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur |
|
[ADJOINT PREFLIGHT] Note de lecture (informatif) : commentaire sticky PR-PATH-COLLISION present (organ #13359/#13615 -- ordre de merge a croiser avec les PRs citees). |
Grain: MED/harness -- lane myia-po-2026:CoursIA -- prev: #18168
Defect
The REST fallback of
fetch_poolcaps its raw stream at 10 pages x 100 = 1000 items (issues AND PRs) and filters PRs during construction, solen(raw)can never reachPOOL_FETCH_LIMIT(2000): the[POOL TRONQUE]guard could not fire on the REST path, whatever the threshold. A REST truncation (as soon as issues + PRs > 1000) was silent -- exactly the biased-toward-recent class the guard exists to prevent (regression path of #17038).Fix
The right signal is the page cap being hit (last page full), not
len(raw):_rest_pagesnow returns(items, hit_cap); both call sites updated (issues + PRs paths).POOL_ISSUES_REST_MAX_PAGES = 10(was the silent default), named in the message as the remedy -- mirrors#17474([PRS TRONQUEES]/POOL_REST_MAX_PAGES) on the PR path.fetch_rawemits[POOL TRONQUE]when the cap is hit, saying explicitly that the filtered count can never reachPOOL_FETCH_LIMITso the main guard is blind on this path.Acceptance (all 4 criteria)
[POOL TRONQUE]on stderr via the REST path. VERIFIED (test passes).POOL_FETCH_LIMITcount -> the count-exact message, not the page-cap one. VERIFIED (new test).scripts/tests/test_pick_idle_grain.py: 2 new tests, 173/173 pass in the file.Validation
python -m pytest scripts/tests/test_pick_idle_grain.py -q-> 173 passed.pick_idle_grain), run from repo root: 1175 passed, 1 skipped, 0 failed._rest_pagesconsumer (grep: 2 call sites, both updated).py_compileOK.Note: invoking pytest from
scripts/(instead of repo root) reddens ~25 unrelated subprocess-spawning tests via cwd-relative path resolution (scripts\scripts\...) -- pre-existing invocation artifact, not touched by this PR; from the repo root everything is green.Closes #18113
🤖 Generated with Claude Code