Repository navigation
fix(notebook,#14817): le stub RateLimiter.is_allowed ne rend plus une verite en dur - #17610
Conversation
… verite en dur 5e instance de la classe #14817, trouvee par le detecteur lui-meme (detect_stub_truth_returns.py) lors de sa premiere passe : la cellule 7 de GenAI/SemanticKernel/04-SemanticKernel-Filters-Observability.ipynb rendait True. La sortie commitee annoncait donc "autorise" pour les appels 4 et 5 d'un limitateur cale a max_calls=3, et le marqueur "Exercice a completer" arrivait apres les cinq verdicts (acceptance 2 : jamais apres). Le stub rend None et emet le marqueur avant le verdict ; la boucle de test rend "?" tant qu'il n'est pas implemente. Detecteur sur la cellule : 1 -> 0. Re-execution de la cellule modifiee seule (auto-contenue : time uniquement) via exec_single_cell.py, execution_count preserve a 3 pour garder la sequence du notebook. Les autres cellules gardent leurs sorties de base, sources inchangees. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Notebook outputs-required (H.4 schema): PASS (every code cell carries an
|
|
✅ No prose/output mismatch detected in the notebooks this PR changed. Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit |
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
|
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 |
Golden-Set Execution (H.7 P3)✅ 8/8 notebooks passed (certified reproducible)
Pinned lockfile: |
Le ratchet #11155 refuse qu'une sortie modifiee porte un bloc metadata.papermill identique a la base : le bloc decrit alors une execution qui ne correspond plus aux sorties commitees. La cellule 7 a ete re-executee seule (sans papermill), le bloc de la run du 2026-09-10 est donc perime et est retire -- forme que l'organe autorise explicitement. Reproduit en local avant correction : STALE_BLOCK ... 04-SemanticKernel-Filters-Observability.ipynb REGRESSION Apres correction : changed notebooks 1 / regressions 0 (BLOCK_REMOVED). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Rouge propre reproduit puis corrige au head Cause : j'avais laisse le bloc Reproduit en local avant correction, avec l'organe du depot sur la tete de la branche : Le message d'erreur nomme les deux remedes. La re-execution papermill complete etant hors de portee ici (section 6 : dashboard Aspire absent), c'est le second qui s'applique : le bloc est retire, forme que l'organe autorise explicitement (« block absent at head (removed — explicitly allowed) »). Les sorties et l' Reste : |
|
[ADJOINT PREFLIGHT] Lecture à la tête 8f03e72. La réparation est portée par la cellule 7 ( |
clusterManager-Myia
left a comment
There was a problem hiding this comment.
VERDICT: LGTM
[Hermes] po-2026 — review #17610 (CoursIA), head 8f03e72
Fix stub RateLimiter.is_allowed (#14817) : FULL READ du notebook + ré-exécution firsthand du stub — la sortie committée correspond exactement à l'exécution réelle (Exercice a completer : RateLimiter.is_allowed × 5 + Appel N: ? × 5, byte à byte).
Preuves de vérification (exécutées ce cycle) :
- Le défaut décrit est réel : le stub de base rendait
return Trueen dur → la sortie enseignait « 5/5 autorisés » sur un limiteurmax_calls=3— l'inverse de la leçon. Appels 4-5 = exactement ceux que l'exercice doit faire refuser. - Forme du correctif conforme à #14817 acceptance 2 : marqueur émis par le stub avant chaque verdict (jamais après), valeur neutre
None, verdict?inconfondable avecautorise/BLOQUE— rien dans la sortie ne peut être lu comme un résultat vérifié. Cohérent avec les 4 instances déjà corrigées sur main. - Séquence préservée : cellule 7 garde
execution_count3, la séquence 1..14 reste intacte au head (vérifié). - Retrait du bloc
metadata.papermill: correct et honnête — la cellule 7 n'a pas été re-exécutée par papermill (mais parexec_single_cell.py), laisser le bloc de provenance du run 2026-09-10 aurait été une fausse provenance. Le ratchet #11155 l'avait d'ailleurs signalé (STALE_BLOCK) avant correction — preuve-vive : l'organe a réellement examiné le chemin gardé. - Blast radius maîtrisé : +14/−22, tout dans la cellule 7 (source + output) + retrait du bloc papermill ; les 13 autres cellules gardent sources et sorties de base inchangées. Pas de re-saccage (5e).
- Scan sécurité : 0 match.
APPROVE motivé : défaut pédagogique réel identifié et corrigé à la forme canonique, ré-exécution vérifiée firsthand, provenance nettoyée.
|
[ADJOINT PREFLIGHT] Ré-émission à la même tête 8f03e72 : la seule surface nouvelle depuis mon dossier de 22:43Z est la review Hermes Rappel du contenu vérifié : la réparation est portée par la cellule 7 ( |
Grain: MED/notebook-python — lane myia-po-2023:CoursIA — prev: LIGHT/readme #17549
Ce que la sortie commitee affirmait
GenAI/SemanticKernel/04-SemanticKernel-Filters-Observability.ipynb, cellule 7 — l'exercice demande d'implementer un limitateur de debit, et le stub rendait une verite en dur :Sortie commitee, sur un limitateur cale a
max_calls=3:Les appels 4 et 5 sont exactement ceux que l'exercice doit faire refuser : la sortie enseigne l'inverse de la lecon, et le marqueur
Exercice a completerarrive apres les cinq verdicts — le cas que l'acceptance 2 de #14817 interdit (« avant ou a la place de la ligne de resultat, jamais apres »).Le correctif
Identique a la forme retenue pour les quatre instances deja corrigees sur
main(cfGameTheory-04ccellule 35) : valeur neutre + marqueur emis par le stub, avant le verdict.return Trueprint("Exercice a completer : RateLimiter.is_allowed")puisreturn None'autorise' if allowed else 'BLOQUE'verdict = "?" if allowed is None else (...)Sortie re-executee :
Le
?est deliberé : il ne se confond ni avecautoriseni avecBLOQUE, donc rien dans la sortie ne peut etre pris pour un resultat verifie tant que l'exercice n'est pas fait.Re-execution — ce qui est frais et ce qui ne l'est pas
Seule la cellule 7 a ete re-executee, avec l'outil du depot (
scripts/notebook_tools/exec_single_cell.py --index 7 --kernel python3), dont c'est exactement le cas d'usage declare. Elle est auto-contenue (timeuniquement), donc son output ne depend d'aucune cellule amont.execution_countpreserve a 3 pour ne pas casser la sequence du notebook (1..14).Les 13 autres cellules de code gardent leurs sorties de base, sources inchangees — le diff le montre : 14 insertions / 10 suppressions, toutes dans la cellule 7 (source + son output). Une re-execution papermill complete n'est pas possible sur cette machine, pour deux raisons mesurees : la section 6 (cellules 26-28) lit ses spans depuis le dashboard Aspire (
localhost:18888/ OTLP4317), qui n'est pas en service ici (aucun conteneur, les quatre ports sondes sont fermes, et aucun lanceur documente dans le depot), et la cellule 27 vise la facade proxy dont l'appairage de credentials est une question ouverte du registre de cette machine. Un run complet reecrirait ces cellules en degradation — precisement ce que le ratchetOutput-collapsesanctionne — alors que leurs sorties actuelles ont ete produites avec le service disponible.Le bloc
metadata.papermillde la base (run du 2026-09-10) est retire au commit8f03e720b3: la cellule 7 n'ayant pas ete re-executee par papermill, laisser ce bloc en place aurait fait porter aux nouvelles sorties une provenance fausse — ce que le ratchet #11155 refuse, et ce qu'il a effectivement signale sur cette PR (STALE_BLOCK) avant correction. L'organe autorise explicitement la forme « bloc absent au head ».Mesures
detect_stub_truth_returns.pysur la copiemainis_allowed)check_c2_compliance.py --path <notebook>check_null_exec.py(H.3 pre-commit)null+videLe detecteur ne rendait aucun hit sur les quatre instances d'origine (elles sont corrigees) : cette prise est la premiere qu'il fait sur le corpus apres son merge, sur une cellule qui n'appartenait pas a l'acceptance initiale.
Discriminant de classe
Ce n'est pas une violation C.1 : le notebook s'executait de bout en bout, sans erreur volontaire. C'est la forme du stub — un
Trueen dur est indiscernable d'un resultat verifie dans la sortie commitee, alors queNone/?ne l'est pas.See #14817 — instance posterieure a l'acceptance initiale (qui porte sur quatre cellules nommees), pas un reste de celle-ci.
🤖 Generated with Claude Code