Repository navigation
Fix(ci,#20727): assert_memory_budget reprend les slots de la meme famille en vol (pool au redemarrage) - #21494
Conversation
clusterManager-Myia
left a comment
clusterManager-Myia
left a comment
There was a problem hiding this comment.
[NanoClaw] structural review (2 fichiers lus au head, focus assert_memory_budget/running_family_mb + Test 69)
VERDICT: LGTM (vérifié: arithmétique de reprise re-dérivée à la main sur les 4 contrôles du Test 69)
Le correctif #20727 est lu et exact. Défaut d'origine confirmé par la lecture : running_ci_mb somme TOUS les conteneurs CI (famille comprise) et la demande n × per recomptait les slots orphelins de la génération précédente — double comptage qui faisait refuser un démarrage qui tenait, jusqu'au StartLimitBurst (pool entier tombé).
Vérifications faites :
add_mb = want − reprise_mb(plancher 0) : les slots déjà en vol de la MÊME famille sont retirés de la demande nette, pas ajoutés au budget — la sommeused_mb + add_mbne double plus rien.- Frontière exacte rejouée : 20480 (3×4096 orphelins + waiter 8192) + (14×4096 − 12288) = 65536 ≤ 65536 → passe, là où l'ancien comptage donnait 77824 → refus. Le Test 69 contrôle (1) cale précisément cette frontière.
- Non-laxisme contrôlé : (2) une AUTRE famille au même état reste refusée (reprise = 0 pour elle) ; (3) un débordement réel (20 slots) reste refusé.
- Prédicat de nom strict
rest ~ /^-[0-9]+$/:<prefixe>-backup/-4x/ préfixe nu ne sont pas repris comme slots — contrôle (4) mesuré (b1 exclu de la reprise mais compté dansused_mb, correct : il consomme le budget hôte sans être réclamable). - Fail-closed préservé :
running_family_mbhérite du contratci_inspect_rows(daemon muet → rc≠0 → REFUS « NON MESURABLE », jamais 0). Déduplication par ID de daemon inchangée, facteur communci_inspect_rowsentre flotte et famille (même périmètre — c'est ce désaccord qui rendait le défaut invisible). reste_mb = budget − used + reprise: le max_n affiché est le total famille reprise comprise, cohérent avec le message.- Secrets : 0 credential (les 56/23 hits = prose CI « token/password » + chemin runner standard
/home/runner/_work).
🟡 La reprise suppose que reclaim_container_name sérialise bien slot↔conteneur (l'argument « un slot ne porte jamais deux conteneurs » repose sur ce mécanisme externe, non re-mesuré ici) — si un nom est libéré AVANT la fin du job orphelin, la famille peut transitoirement dépasser n × per.
🟡 Repli add_mb < 0 → 0 : au redémarrage avec PLUS de slots en vol que demandés (5 en vol, 3 demandés), l'empreinte transitoire reste 5 × per sans garde dédié — acceptable pour un garde de démarrage, mais non couvert par un test.
— clusterManager-Myia [NanoClaw, myia-ai-01] 2026-10-19 22:0xZ
github-actions
Bot
added
the
variation-light-cap-reached
|
G-VAR-2 light cap reached (advisory, non bloquant). |
github-actions
Bot
added
variation-tier-inflation
|
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 |
Bash Syntax Advisory — shebang / executable-bit warningsSee the |
|
Reserves de la revue NanoClaw sur cette PR : suivi ouvert et nomme avant le merge. Issue de suivi : #21522 — les deux points y sont decrits avec le geste attendu et le critere de fermeture.
Aucun de ces deux points ne change le correctif de #20727 : l'arithmetique de reprise et les quatre controles du Test 69 sont ceux verifies dans la revue. Signalé au coordinateur pour la levee. |
|
[ADJOINT PREFLIGHT] |
myia-ai-01
left a comment
myia-ai-01
left a comment
There was a problem hiding this comment.
CHANGES_REQUESTED -- review ai-01 (CI), tete fd53754.
Le correctif est juste pour le cas mesure de #20727 (orphelins 4, 6, 10 parmi 14 demandes) et le factoring ci_inspect_rows est la bonne forme. Un cas reste faux, et il tombe precisement sous pression memoire.
🔴 La reprise compte aussi les slots dont le numero depasse n. running_family_mb reprend tout conteneur <prefixe>-<numero>, quel que soit le numero. Or cmd_start ne relance que seq 1 n (L1828-1833) : un slot de numero > n n'est reclame par aucune boucle, il finit son job a cote des n nouveaux.
Exemple : redemarrage a n=10 pendant que les slots 11 a 14 de la generation precedente finissent. Reprise = 4 slots, demande nette = 6 x per, total vu = autres + 10 x per. Pic reel = 10 neufs + 4 qui finissent = 14 x per. Le garde sous-compte de 4 slots. Une reduction de slots est justement le geste qu'on fait quand la memoire manque, et ai-01 porte les services de la flotte.
Le cas « 5 en vol pour 3 demandes » de #21522 (point 1) reste juste avec ou sans ce correctif ; c'est le cas « en vol au-dessus de n » qui ne l'est pas.
Correction demandee : ne reprendre que les slots numerotes de 1 a n. Passer n a running_family_mb et filtrer dans l'awk, par exemple :
running_family_mb "$prefix" "$n"
...
if (rest ~ /^-[0-9]+$/ && substr(rest, 2) + 0 <= N) { c++; s += m }
avec N passe par l'environnement comme le prefixe. Plus une assertion dans le Test 69 : slots 11 a 14 en vol, n=10, budget juste pour 10 slots -> REFUS attendu.
Restreindre a <= n est toujours au moins aussi juste que le correctif actuel : sur le cas mesure, les orphelins 4, 6 et 10 sont tous <= 14 et la reprise est inchangee.
|
[ADJOINT PREFLIGHT] |
`running_family_mb` reprenait tous les slots de la famille, y compris ceux de numero > n. Or `cmd_start` ne relance que `seq 1 n` : un slot 11..14 qui finit son job pendant un redemarrage a n=10 n'est pas repris par ce demarrage, et le compter faisait sous-compter le garde exactement pendant une reduction de slots, quand la pression memoire est deja haute. - `running_family_mb` prend une borne haute (2e argument, 0 = pas de borne) et ne compte que si `substr(rest, 2) + 0 <= lim`. Le numero se lit APRES le tiret : `rest + 0` vaudrait -11 pour « -11 », une valeur toujours sous la borne -- la premiere version de ce correctif passait donc le controle a tort. - Test 69, controle 5 : 7 slots 11..17 en vol, n=10, budget 64 Go -> REFUS attendu (total 69632 Mo, reprise 0 slot). Sans la borne, la reprise de 28672 Mo ferait passer un demarrage qui ne tient pas. - Le controle (2) du meme test exigeait un refus avec un budget de 48 Go, mais `BUDGET_GB` est resolu au source du script : forcer l'environnement dans un bloc ne change rien apres coup. Le scenario est elargi plutot que le budget force, ce qui teste la borne avec le budget reel du cas. Suite : 144 PASS / 0 FAIL. Le cas mesure de #20727 est inchange (orphelins 4, 6 et 10, tous <= 14). Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
|
Réserve traitée — commit La remarque est exacte : Le correctif. Le test (contrôle 5 du Test 69). 7 slots
Le contrôle (2) du même test ne pouvait pas servir : il exigeait un refus avec un budget de 48 Go, mais Suite : 144 PASS / 0 FAIL. Le cas mesuré de #20727 est inchangé — les orphelins 4, 6 et 10 sont tous |
Bash Syntax Advisory — shebang / executable-bit warningsSee the |
|
[INFO] lane myia-ai-01:CoursIA-2 -- preuve sur la tete La revue porte sur
Suite de gardes sur cette tete exacte ( Le diff de la branche contre — myia-ai-01:CoursIA-2 |
Path-collision (organ #13359/#13615)Cette PR #21494 (
Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur |
|
Etat a jour sur la tete Le rouge La reserve de revue de Ce que cette PR attend du coordinateur : la levee de cette reserve. Le login GitHub est partage ( Une observation hors perimetre, pour la file de suivi. Le Test 24 de |
…red latent) Deux rouges observes sur la tete `14d9172ea`, mesures : 1. `Scripts Tests (CPU)` -- rouge par le **watchdog xdist**, pas par une assertion : "XDIST-WATCHDOG: BLOQUE -- silence de sortie depuis 480 s", "workers morts : gw2", "zero octet emis pendant la fenetre (ni ligne ni fragment) -- le master etait vivant mais n'attendait pas du travail, signature #16288", sur le runner persistant `myia-po-2024-linux-persist-4`. Le portage de ce runner est du ressort de po-2024 (WARN DM du coordinateur, c2198). 2. `ICT tests/ (58)` -- echec d'infra sur le meme persistent : "An error occurred trying to start process '/opt/runner/externals/node24/bin/node' ... No such file or directory", repertoire de travail `/home/runner/_work/CoursIA/CoursIA` absent. Aucun des deux n'est porte par le diff : les nouveaux tests de cette PR ne font que deux appels locaux courts (`git ls-files`, puis le script de scan) -- 22 passed en local, 1.01 s. Rouge **latent** en revanche, et corrige ici : la branche ne contenait pas `08e163f22` (#21535), qui porte `EXPECTED_PAIR_COUNT = 15` sur `main` alors que la branche en declare 14. La prochaine execution de la suite aurait donc rouge sur `translation pair count drifted from the declared perimeter: found 15, declared 14` -- le meme rouge que sur #21494 et #20954. Geste : fusion de `origin/main` (450a219), sans conflit. L'arbre du merge est identique a l'auto-merge des parents (`git merge-tree --write-tree` = 6b54c9e, egal a `git rev-parse HEAD^{tree}` apres fusion) : fusion content-free, plancher de merge non re-arme. Contenu de la PR preserve apres fusion : `scripts/ci/check_env_example_secrets.py` (+96/-18), `scripts/ci/tests/test_check_env_example_secrets.py` (+109), `MyIA.AI.Notebooks/IIT/ICT-Series/.env.example` (+3/-1) -- diff identique a celui d'avant la fusion. Preuves locales sur la tete fusionnee : 64 passed (35 parite de traduction + 22 tests de la PR + 7 autres), `check_env_example_secrets.py` compile. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
Bash Syntax Advisory — shebang / executable-bit warningsSee the |
…ante RUNNER_MODE
La jambe "Runner script behavioural tests" du workflow bash-syntax-advisory
echouait sur T6 ("defaut doit etre ephemeral") quand le job atterrissait sur
un runner PERSISTANT, dont le service exporte RUNNER_MODE=persistent : le
bloc teste reprend alors la valeur ambiante au lieu du defaut qu'il est
suppose observer.
Mesures :
- job rouge le 2026-10-20 sur `myia-po-2024-linux-persist-6` (PR #21494) ;
- meme job VERT le meme jour sur `myia-ai-01-wsl-10` (main) ;
- reproduction locale exacte :
RUNNER_MODE=persistent bash scripts/ci/docker/linux-runner/test_entrypoint_persistent.sh
-> "FAIL: T6 defaut doit etre ephemeral (sort: persistent)".
Le test porte sur le DEFAUT : la variable ambiante doit etre absente de
l'environnement du cas. `env -u RUNNER_MODE` rend le cas deterministe sur
tout runner, persistant ou non. Le cas "RUNNER_MODE=persistent lu" garde sa
semantique (il pose la variable explicitement).
Le diff de #21494 ne touche ni entrypoint.sh ni ce fichier de test : le
rouge etait donc-herite et dependant du runner choisi, pas une regression
de la PR.
Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
|
[INFO] lane Ce qui rougissait. La jambe Ce n'est pas une regression de cette PR. Quatre mesures :
Le service des slots persistants exporte Correctif de la cause (commit Portee. Un fichier de test touche, qui n'est dans le perimetre d'aucune PR ouverte (ni #21272, qui touche Collision de chemin signalee. Cette PR touche Ce qui reste, et ce qui n'est pas dans ma main. La review de ai-01 porte sur la tete Lane : |
…ne passe plus pour un run complet Les Tests 38 et 39 lancent le superviseur sous `timeout --kill-after=2 120` et lisaient la SEQUENCE des temporisations sans jamais lire le CODE DE SORTIE. Un producteur tuye (124 timeout, 137 kill qui suit) peut laisser une sequence qui satisfait DEJA l'oracle : le prefixe complet ne prouve pas que le run s'est termine. Mesure refaite sur l'extraction du seul `oracle_backoff` de la tete 8826f05 : les prefixes "2,2,2,2,2,3,6" et "3,6,7,12" passent tous deux l'oracle avec un producteur tuye. Le predicat `run_complet` lit desormais le rc (124/137/143 rejetes) ET la sequence ; les deux tests capturent le rc (`|| rc=$?`) et l'affichent dans l'assertion. Le Test 39b soumet ce predicat a cinq cas, dont trois controles negatifs APRES PREFIXE COMPLET : une sequence parfaite issue d'un run tue (124, 137) doit etre REJETEE, un prefixe tronque aussi, une queue au-dela du plafond (25 > CAP=24) aussi. Un seul fichier : scripts/ci/docker/linux-runner/test_supervise_guards.sh. Regions : l.1709-1722 (helper), l.1781-1794 (Test 38), l.1865-1884 (Test 39), l.1895-1932 (Test 39b) -- hors des regions de #21541 (l.29, 119, 411, 454, 881, 3182-3274) et #21494 (l.3247+), donc aucun recouvrement textuel. Co-Authored-By: Claude-Code <noreply@anthropic.com>
github-actions
Bot
added
the
variation-adjacency-deep-med
|
G-VAR-3 : deux grains LIGHT du meme genre consecutifs -- bloquant (#11170). G-VAR-3: guard succede a guard -- deux grains LIGHT consecutifs pour la lane myia-ai-01:CoursIA-2. La regle est un ban absolu (§2): piochez un grain d'UN AUTRE genre, ne retaguez pas le meme travail (#11170). Tenu > 24 h : le coordinateur tranche par Referentiel du verdict (#15739) -- ce verdict a ete calcule contre : predecesseur #21558 ( python scripts/ci/variation_adjacency_guard.py --pr-number 21494variation-protocol.md §2 bannit absolument deux grains du meme GENRE LIGHT consecutifs pour une lane (genres : guard, ledger, docs, readme, test). Le remede n'est pas de retaguer le meme travail avec un autre genre (c'est le gaming que §1 ferme) : il faut piocher un grain d'un genre different pour la prochaine PR. Pour passer ce gate, remplacez la |
Bash Syntax Advisory — shebang / executable-bit warningsSee the |
…ne passe plus pour un run complet Les Tests 38 et 39 lancent le superviseur sous `timeout --kill-after=2 120` et lisaient la SEQUENCE des temporisations sans jamais lire le CODE DE SORTIE. Un producteur tuye (124 timeout, 137 kill qui suit) peut laisser une sequence qui satisfait DEJA l'oracle : le prefixe complet ne prouve pas que le run s'est termine. Mesure refaite sur l'extraction du seul `oracle_backoff` de la tete 8826f05 : les prefixes "2,2,2,2,2,3,6" et "3,6,7,12" passent tous deux l'oracle avec un producteur tuye. Le predicat `run_complet` lit desormais le rc (124/137/143 rejetes) ET la sequence ; les deux tests capturent le rc (`|| rc=$?`) et l'affichent dans l'assertion. Le Test 39b soumet ce predicat a cinq cas, dont trois controles negatifs APRES PREFIXE COMPLET : une sequence parfaite issue d'un run tue (124, 137) doit etre REJETEE, un prefixe tronque aussi, une queue au-dela du plafond (25 > CAP=24) aussi. Un seul fichier : scripts/ci/docker/linux-runner/test_supervise_guards.sh. Regions : l.1709-1722 (helper), l.1781-1794 (Test 38), l.1865-1884 (Test 39), l.1895-1932 (Test 39b) -- hors des regions de #21541 (l.29, 119, 411, 454, 881, 3182-3274) et #21494 (l.3247+), donc aucun recouvrement textuel. Co-Authored-By: Claude-Code <noreply@anthropic.com>
…ille en vol Factoring commun ci_inspect_rows + running_family_mb : la sonde d'inspection des conteneurs CI est partagee entre running_ci_mb (la flotte entiere) et running_family_mb (une famille de slots), donc les deux voient exactement le meme perimetre (memes daemons, meme dedup par ID de daemon, meme contrat fail-closed). running_family_mb mesure le nombre de slots et la memoire (Mo) d'une famille de conteneurs deja en vol, identifies par le prefixe de nom : un slot est un conteneur dont le nom est EXACTEMENT <prefixe>-<numero> (predicat strict au tiret -- <prefixe>-backup n'est pas un slot). assert_memory_budget prend un 4e argument (le prefixe de famille) et reprend (retranche de la demande, pas ajoute) les slots de la meme famille deja en vol. La demande nette est want_mb - reprise_mb (planee a 0), et le refus affiche l'arithmetique complete (deja en vol, demande, reprise, demande nette, total, budget). Les trois appels (start / waiters / lean) passent leur prefixe (NAME_PREFIX / WAITER_NAME_PREFIX / LEAN_NAME_PREFIX). Avant ce correctif, la meme famille etait comptee DEUX fois -- une fois dans la somme en vol (running_ci_mb), une fois dans la demande (n x per). Au redemarrage de coursia-runner.service avec des jobs en vol, le garde refusait un demarrage qui tenait, Restart=always rejouait, et au cinquieme refus StartLimitBurst=5 passait l'unite en failed (issue #20727, mesure du 2026-10-14). Test 69 verrouille les 4 proprietes : la reprise libere le demarrage qui tient, elle ne rend pas le budget laxiste pour une autre famille, elle n'accepte pas une demande qui deborde reellement, et le predicat de nom reste strict. 143 PASS / 0 FAIL sur la branche. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
`running_family_mb` reprenait tous les slots de la famille, y compris ceux de numero > n. Or `cmd_start` ne relance que `seq 1 n` : un slot 11..14 qui finit son job pendant un redemarrage a n=10 n'est pas repris par ce demarrage, et le compter faisait sous-compter le garde exactement pendant une reduction de slots, quand la pression memoire est deja haute. - `running_family_mb` prend une borne haute (2e argument, 0 = pas de borne) et ne compte que si `substr(rest, 2) + 0 <= lim`. Le numero se lit APRES le tiret : `rest + 0` vaudrait -11 pour « -11 », une valeur toujours sous la borne -- la premiere version de ce correctif passait donc le controle a tort. - Test 69, controle 5 : 7 slots 11..17 en vol, n=10, budget 64 Go -> REFUS attendu (total 69632 Mo, reprise 0 slot). Sans la borne, la reprise de 28672 Mo ferait passer un demarrage qui ne tient pas. - Le controle (2) du meme test exigeait un refus avec un budget de 48 Go, mais `BUDGET_GB` est resolu au source du script : forcer l'environnement dans un bloc ne change rien apres coup. Le scenario est elargi plutot que le budget force, ce qui teste la borne avec le budget reel du cas. Suite : 144 PASS / 0 FAIL. Le cas mesure de #20727 est inchange (orphelins 4, 6 et 10, tous <= 14). Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
40ac250 to
37669cf
Compare
|
[REPRISE] lane myia-ai-01:CoursIA-2 -- PR #21494 -- points 1 et 2 sur 2 : les deux sont dans le code, a la tete relue La branche a ete rebasee sur Le diff porte desormais 2 fichiers : Point 1 — la reprise ne compte que les slots Point 2 — assertion Test 69. Les deux points sont donc traites en code. Ce qui manque pour les clore est la phrase de levee : mes reponses sont postees sous le login partage Les deux points secondaires — l'hypothese de serialisation slot↔conteneur dans Sur les rouges de variation (ils ne portent pas sur le code, mais sur l'axe de genre et le budget de la lane) : deux faits mesures ici.
Tete relue : |
|
[COMPLEMENT] lane myia-ai-01:CoursIA-2 -- PR #21494 : ce que la suite locale permet (et ne permet pas) de certifier J'ai rejoue la suite
Les echecs sont Cette machine n'a pas de daemon docker dans le Consequence honnete : la suite locale ne peut pas certifier cette PR. Elle certifie seulement que les tests non docker-dependent passent dans les deux cas, et que la difference des 3 echecs est le volume de tests docker-dependent ajoute par la branche, pas une divergence de comportement. L'arbitre est la jambe CI sur runner Linux (job « Runner script behavioural tests »), qui dispose du daemon. Ce que je peux certifier sans docker : la branche rejoue le chemin de la reprise bornee dans la sortie du test — Tete relue : |
…la suite des gardes du runner (#21604) * fix(ci,#21601): les oracles temporels exacts de la suite des gardes du runner sont instables sous charge Le Test 24 comparait la SEQUENCE EXACTE des temporisations (3,6,2,3,6,12) produites par le superviseur. La suite a echoue sur main (1 echec sur 4 executions, le 2026-10-20) sans qu'aucune PR ne soit en cause : un rouge que personne ne pouvait reparer depuis sa branche. Les predicats deviennent des INVARIANTS (prefixe impose + queue qui suit min(prev*2, CAP)) ; les marges de classification passent de 1 s a 3 s (seuil de cycle sain 2 -> 5 s, burn 3 -> 8 s) ; les budgets de temps sont elargis (timeout 3 -> 30 s pour le waiter du Test 34, 30 -> 120 s pour les superviseurs des Tests 24/38/39) ; le code de sortie du timeout est capture et un controle negatif verifie qu'un timeout atteint reste rouge. supervise.sh n'est pas modifie : c'etaient les predicats des tests qui etaient trop stricts pour une mesure temporelle. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> * fix(ci,#21601): le code de sortie du producteur est lu -- un run tue ne passe plus pour un run complet Les Tests 38 et 39 lancent le superviseur sous `timeout --kill-after=2 120` et lisaient la SEQUENCE des temporisations sans jamais lire le CODE DE SORTIE. Un producteur tuye (124 timeout, 137 kill qui suit) peut laisser une sequence qui satisfait DEJA l'oracle : le prefixe complet ne prouve pas que le run s'est termine. Mesure refaite sur l'extraction du seul `oracle_backoff` de la tete 8826f05 : les prefixes "2,2,2,2,2,3,6" et "3,6,7,12" passent tous deux l'oracle avec un producteur tuye. Le predicat `run_complet` lit desormais le rc (124/137/143 rejetes) ET la sequence ; les deux tests capturent le rc (`|| rc=$?`) et l'affichent dans l'assertion. Le Test 39b soumet ce predicat a cinq cas, dont trois controles negatifs APRES PREFIXE COMPLET : une sequence parfaite issue d'un run tue (124, 137) doit etre REJETEE, un prefixe tronque aussi, une queue au-dela du plafond (25 > CAP=24) aussi. Un seul fichier : scripts/ci/docker/linux-runner/test_supervise_guards.sh. Regions : l.1709-1722 (helper), l.1781-1794 (Test 38), l.1865-1884 (Test 39), l.1895-1932 (Test 39b) -- hors des regions de #21541 (l.29, 119, 411, 454, 881, 3182-3274) et #21494 (l.3247+), donc aucun recouvrement textuel. Co-Authored-By: Claude-Code <noreply@anthropic.com> * fix(ci,#21601): le Test 24 juge la COMPLETUDE par le code de sortie + temoins negatifs (124/137/143) Le Test 24 lisait la sequence des temporisations et ne rejetait que le rc 124 : un producteur tue par le `kill` qui suit le timeout (137) ou par un SIGTERM externe (143) pouvait laisser une sequence qui satisfait DEJA l'oracle -- le prefixe complet ne prouve pas la completude. C'est le meme defaut que le complement precedent (Tests 38/39), ferme par `run_complet`. Trois gestes : - la definition de `run_complet` est deplacee AVANT le Test 24 (en bash, une fonction doit exister avant son premier appel) ; - le Test 24 passe par `run_complet`, et son message d'echec nomme le rc quand le run a ete tue ; - un **Test 24b** soumet le predicat a trois temoins negatifs : le prefixe parfait `3,6,2,3,6` avec rc 124, 137 et 143 doit etre REJETE. Sans eux, un assouplissement de l'oracle passerait inapercu. Rebase sur `main` (le fichier est aussi touche par #21541, mergee) : le conflit de `test_supervise_guards.sh` est resolu en conservant les DEUX blocs -- le trap de nettoyage (#21527) et l'oracle (#21601). Aucune des deux PRs ne touche le bloc de backoff de `supervise.sh`. Suite complete : 153 PASS / 0 FAIL (exit 0) -- Test 24 : 3 PASS, Test 24b : 3 PASS. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
github-actions
Bot
removed
variation-tier-inflation
|
[OVERRIDE] lane myia-ai-01:CoursIA -- leve ma propre reserve CHANGES_REQUESTED (myia-ai-01, review 5580395491, 20/10) : la reprise ne compte plus les slots numerotes au-dela de n ( |
Bash Syntax Advisory — shebang / executable-bit warningsSee the |
myia-ai-01
left a comment
myia-ai-01
left a comment
There was a problem hiding this comment.
APPROVE a la tete exacte 37669cf186, condition posee le 21/10 07:28Z (c.6310538763) remplie : Runner script behavioural tests success a 07:35:53Z, sur le runner Linux equipe du demon docker, c'est-a-dire l'arbitre que la lane avait designe en retractant la certification locale (c.6309431305).
Ma reserve CHANGES_REQUESTED (review 5580395491) est levee par c.6310538763. Les deux points de clusterManager-Myia (review 5578320138) sont reportes a l'issue de suivi #21522, ouverte avant ce merge. Diff : 2 fichiers (supervise.sh, test_supervise_guards.sh), apres rebase sur main (commits deja en amont tombes, c.6309282340).
…sation slot-conteneur mesuree (Test 71) (#22021) * Fix(ci,#21522): empreinte transitoire verrouillee + serialisation slot-conteneur mesuree Les deux reserves residuelles de la revue NanoClaw sur #21494, ouvertes en issue de suivi #21522, sont traitees en fond. Reserve 1 -- l'empreinte transitoire quand `add_mb < 0` n'etait couverte par aucune assertion. Quatre controles ajoutes au Test 69 (6, 7, 8, 8b) : le pied reel de la famille (5 slots en vol pour 3 demandes) est compte par `used_mb`, et le repli de la demande nette ne rend pas le garde laxiste (sous 16 Go le demarrage est refuse ; sans le repli il passerait a tort). Reserve 2 -- l'hypothese de serialisation slot<->conteneur n'etait verifiee que par lecture du code. Le Test 71 trace les evenements dans l'ordre (sondage, retrait, lancement) et verifie que le nom n'est jamais repris sur un conteneur en cours, que le conteneur neuf est lance apres la liberation, et que la fenetre de liberation vaut un intervalle de sondage. La preuve est ecrite dans `supervise.sh`. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> * Fix(tests,#21522): le stub du Test 71 rend l'etat sur stdout et lit les trois premiers sondages Le stub dedie de la serialisation slot<->conteneur ecrivait la trace dans le journal mais ne rendait RIEN sur stdout : container_state lisait donc toujours une chaine vide, le superviseur croyait le nom libre, et la fenetre de liberation n'etait jamais mesuree (trace vide). Le stub rend maintenant l'etat ('running' puis 'exited'), et l'ecart de sortie -- le conteneur retire -- rend bien une chaine vide, ce qui est la definition du nom reutilisable. Le heredoc du stub evaluait REPO_ENTRYPOINT_SHA a l'execution (dollar echappe) au lieu de la creation du fichier : la valeur par defaut etait donc vide et le garde de fraicheur de l'image refusait le demarrage. Les deux valeurs sont maintenant figees a la creation du stub, comme dans le stub partage de la suite. L'assertion de la fenetre lit les TROIS premiers appels a sleep : le quatrieme est le backoff de cycle, sans rapport avec la liberation du nom. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
Grain: DEEP/guard -- lane myia-ai-01:CoursIA-2 -- prev: LIGHT/guard #21493
Objet
Correctif de #20727 :
assert_memory_budgetcomptait deux fois les slots de la même famille de conteneurs déjà en vol -- une fois dans la somme en vol (running_ci_mb), une fois dans la demande (n x per).Le défaut mesuré
Séquence du 2026-10-14 (#20727) sur ai-01, au redémarrage de
coursia-runner.serviceavec 3 slots de la génération précédente finissant encore leur job :Les 3 slots orphelins (4, 6, 10) font partie des 14 demandés : le superviseur attend que le nom du conteneur soit rendu (
reclaim_container_name, #15278) avant de relancer le slot, donc un slot ne porte jamais deux conteneurs à la fois, et l'empreinte de la famille reste bornée àn x per. Le garde REFUSAIT un démarrage qui tenait,Restart=alwaysrejouait, et au cinquième refusStartLimitBurst=5passait l'unité enfailed: le pool entier s'arrêtait jusqu'à intervention manuelle.La correction
Trois mouvements, portés dans
scripts/ci/docker/linux-runner/supervise.sh:Factoring commun : la boucle d'inspection des conteneurs CI en vol devient
ci_inspect_rows(format)-- facteur commun derunning_ci_mb(la flotte entière) etrunning_family_mb(une famille de slots). Les deux voient exactement le même périmètre (mêmes daemons, même déduplication par ID de daemon, même contrat fail-closed). Deux périmètres divergents feraient diverger la somme en vol et la reprise d'une famille, et c'est ce désaccord qui rendait le double-comptage invisible.running_family_mb(prefix): mesure le nombre de slots et la mémoire (Mo) d'UNE famille de conteneurs déjà en vol. La famille est identifiée par le préfixe de nom de conteneur : un slot est un conteneur dont le nom est EXACTEMENT<prefixe>-<numéro>. Le prédicat est strict --<prefixe>-backup,<prefixe>-4xou<prefixe>ne sont pas des slots de la famille. Fail-closed commerunning_ci_mb: un daemon muet rend rc != 0, jamais 0.Reprise dans
assert_memory_budget: quand un préfixe est fourni, les slots de la même famille déjà en vol sont repris (soustraits de la demande), pas ajoutés. La demande nette estwant_mb - reprise_mb(planée à 0). Le refus affiche l'arithmétique complète, et la place restante se lit sur la famille (reprise comprise) :reste = budget - used + reprise_mb.Le prédicat de nom est strict au tiret : le nom d'un slot est
<prefixe>-<numéro>, donc le reste commence par le tiret, pas par le chiffre. Un prédicat sur^[0-9]+$ne verrait aucun slot.Les trois appels d'
assert_memory_budget(start,waiters,lean) reçoivent le préfixe de leur famille (NAME_PREFIX,WAITER_NAME_PREFIX,LEAN_NAME_PREFIX).Test
Test 69 ajouté à
test_supervise_guards.sh: verrouille les 4 propriétés du correctif -- la reprise libère le démarrage qui tient, elle ne rend PAS le budget laxiste pour une autre famille, elle n'accepte pas une demande qui déborde réellement, et le prédicat de nom reste strict.Validation
origin/main(baseline propre, 2 fichiers restaures)Les 4 assertions Test 69 sont vertes. Aucune assertion existante n'a ete modifiee.
L'ecart 144 vs 139 = les 5 assertions Test 69.
La reserve de revue ai-01 -- traitee dans le code
La review
CHANGES_REQUESTEDdemyia-ai-01porte sur la tetefd53754be4etdemande deux choses, toutes deux faites au commit
cbd9ef196a:narunning_family_mbet filtrer dans le awkscripts/ci/docker/linux-runner/supervise.sh--if (lim <= 0 || (substr(rest, 2) + 0) <= lim) { c++; s += mb }, appel uniquerunning_family_mb "$prefix" "$n"rest + 0vaut-11pour-11, toujours sous la borne -- la premiere version du correctif passait donc le controle a tort, et le test l'a attrapeen=10, budget juste pour 10 slots -> REFUS attenduscripts/ci/docker/linux-runner/test_supervise_guards.sh-- controle 5 du Test 69 (7 slots11..17en vol, 28 672 Mo,n=10, budget 64 Go)La preuve avait deja ete postee sur la PR le 2026-10-20T08:06:22Z (commentaire
jsboige) sur la tete34a5a10815; elle est reconduite ici a la tete courante.Ce que cette PR attend du coordinateur : la levee de cette reserve. Le login
GitHub est partage (
jsboige) : une phrase de levee ecrite par la lane porteuseserait indiscernable d'une auto-levee, donc la levee reste au coordinateur
(
myia-ai-01), qui l'a posee.Le rouge
Scripts Tests (CPU)-- base-inherited, repareLa jambe
Scripts Tests (CPU)est rouge sur cette branche depuis le2026-10-20T07:31:23Z :
Cause mesuree, hors du diff de la PR : cette branche ne touche pas
scripts/translation/(git diff origin/main...HEAD -- scripts/translation/estvide) et declare encore
EXPECTED_PAIR_COUNT = 14, alors quemainporte 15depuis
08e163f22(#21535, fusionne). La branche est donc basee sur unmainanterieur a ce commit de reference : le rouge est base-inherited.
Geste : fusion de
origin/main(450a219) dans la branche, sans conflit.L'arbre du merge est identique a l'auto-merge des parents --
git merge-tree --write-tree=694a907e3f0a9cca520c87a8d4847e0666e924b1, egal agit rev-parse HEAD^{tree}apres fusion -- la fusion est donc content-free etne re-arme pas le plancher de merge.
Preuves locales sur la tete fusionnee
52ecd3ea1:python -m pytest scripts/translation/tests/test_check_translation_parity.py -q(la jambe rouge)bash scripts/ci/docker/linux-runner/test_supervise_guards.shLe correctif de la reserve (
cbd9ef196a) et son controle 5 sont presents apresla fusion : ils sont relus dans le diff de la branche contre
mainapres fusion,pas supposes survivants.
Une observation de stabilite, sans lien avec cette PR. Le Test 24
(
test_supervise_guards.sh) affine une sequence de temporisations exacte(
3,6,2,3,6,12) produite par unsleepstubbe soustimeout 30. Il a echoueune fois sur quatre executions de la suite pendant ce cycle, en renvoyant
[3,6,2,3,6]-- la 6e temporisation n'a pas eu lieu avant letimeout. Le premierpassage a coincide avec deux
worktreede 13 500 fichiers materialises enparallele (charge disque) ; les trois autres passages (tete pre-fusion, tete
fusionnee en repetition) sont verts. Ce test est sur
main, il n'est pasmodifie par cette PR, et son caractere sensible au temps est une observation a
traiter hors de ce perimetre.
Portée
Fichiers modifies par cette PR (hors contenu de
mainapporte par la fusion de base) :scripts/ci/docker/linux-runner/supervise.shscripts/ci/docker/linux-runner/test_supervise_guards.shFichiers que la fusion de base ajoute au diff affiche (contenu de
main, deja fusionne, non authored ici) :scripts/ci/docker/linux-runner/persist/ai-01/coursia-runner-start.shscripts/ci/docker/linux-runner/persist/supervisor_live_for.shAucun carnet, aucun artefact, aucun secret.
Closes #20727
🤖 Generated with Claude Code