Le relevé d'ordre 3D pariait sur une durée au lieu d'attendre - #5
Merged
Conversation
La CI Windows du 2026-08-17, sur main, a fait tomber « ordre = axe 3D fait suivre au chase la scéno, pas la liste ». Le relevé rendait ["bar1","bar2","bar3"] au lieu de ["bar1","bar2","bar3","bar0"]. L'ordre n'était pas faux : il était TRONQUÉ. Les trois barres relevées sont les trois premières de l'ordre géométrique attendu — un ordre cassé aurait rendu l'ordre de la liste (bar0, bar1, bar2), c'est-à-dire une réponse différente, pas une réponse plus courte. Le quatrième pas n'était simplement pas encore arrivé. `ordreVu()` attendait 560 ms pour quatre pas de 120 ms, soit 80 ms de marge. Sur un runner chargé qui fait tourner une dizaine de serveurs en parallèle, ça ne tient pas. C'est le piège écrit dans le CLAUDE.md : un test qui mesure une grandeur qui évolue doit être long devant le bruit de charge. Le relevé attend désormais la CONDITION — les quatre barres — au lieu de parier sur une durée, avec un plafond de 3 s pour rester borné si le chase ne démarre pas. Il est donc indépendant de la vitesse de la machine, et il ne ralentit rien sur une machine rapide : il sort dès que le compte y est. Mesuré, le fichier met 59,2 s contre 59,5 s avant. ⚠ Le CLAUDE.md prévient qu'élargir une fenêtre au hasard a déjà fait passer une suite de 1 à 19 échecs. Ici l'élargissement est sûr, et c'est démontrable : chaque barre n'est retenue qu'à son PREMIER allumage, donc les cycles suivants du chase sont ignorés. Attendre plus longtemps ne peut rien ajouter de faux. Et le test n'a pas été rendu complaisant : vérifié en cassant l'ordre 3D pour de bon dans un clone (`list = [...list]`, le tri géométrique supprimé) — la suite tombe. Il mord toujours. 346 tests, 0 ignoré. dist/ synchrone. Aucun changement dans le code livré.
Second échec de la CI Windows sur main, le même jour, et pour une raison différente du premier — celui-ci ne fait tomber aucun test : # tests 346 # pass 300 # fail 0 # cancelled 46 # skipped 0 Zéro échec, mais les 46 tests d'interface ANNULÉS, et le job rouge. La cause réelle était noyée sous 46 lignes « did not finish before its parent » : le `before` de ui.test.js avait levé « le navigateur n'a pas démarré ». `attendreDevTools` accordait 20 s à Edge pour répondre sur son point d'entrée DevTools. Le même runner avait fait passer ces 46 tests deux fois le jour même : ce n'est donc pas un refus de démarrer, c'est la charge de la machine. Le délai passe à 60 s. Attendre plus longtemps ne coûte rien quand tout va bien : la boucle sort dès que DevTools répond, en général sous la seconde. Ça ne coûte que dans le cas déjà perdu, où le navigateur ne démarrera jamais — et là, échouer 40 s plus tard ne change rien à personne. ⚠ À savoir pour la prochaine fois : quand ce `before` lève, les 46 tests s'annoncent « cancelled » SANS dire pourquoi, et le compte reste à 346. Ni le nombre de tests ni le nombre d'échecs ne signalent quoi que ce soit — seul `cancelled` le fait. Le message d'erreur dit désormais le délai attendu, pour qu'on ne recherche plus la cause à l'aveugle. 346 tests, 0 annulé, 0 ignoré. Aucun changement dans le code livré.
Troisième échec de la CI Windows, encore une autre cause — et celle-ci accusait
le produit à tort :
« la statistique du bruit ne devrait pas dependre de l axe :
0.1087 contre 0.2149 »
Or 0,2149 est la valeur NOMINALE des deux azimuts, celle que le commentaire du
test cite lui-même. Ce n'est donc pas l'axe qui a bougé : c'est le premier
relevé qui s'est effondré de moitié. Un écart-type ne s'effondre que d'une
façon — des valeurs plates. Les tout premiers `state()` arrivaient avant le
premier tick du champ, sur une machine chargée, et un relevé plat sur dix suffit
à diviser la dispersion par deux.
La mesure laisse maintenant le champ s'établir (150 ms) et prend 20 relevés au
lieu de 10, pour que la statistique converge.
⚠ Le seuil de 15 % n'est PAS touché. Il avait été resserré depuis 50 % sur
mesure, parce que 50 % laissait passer une dépendance à l'axe de 40 % — soit
précisément le défaut que ce test interdit. Face à un test qui tombe, élargir la
tolérance est la correction tentante et la mauvaise : c'est la mesure qu'on
fiabilise, jamais l'exigence qu'on relâche.
Et le test n'a pas été rendu complaisant : les deux mutations qui le visent —
« etalement du bruit revenu a la version rejetee » et « normalisation par
l'etendue de l'axe remplacee par une constante » — sont toujours détectées,
vérifié dans un clone.
Coût : 61 s au lieu de 59 s sur ce fichier. 346 tests, 0 ignoré.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Objectif
La CI Windows a fait tomber
mainsur un test d'ordre 3D. Le logiciel n'estpas en cause : c'est le test qui pariait sur une durée au lieu d'attendre.
Relevé obtenu :
["bar1","bar2","bar3"]— attendu["bar1","bar2","bar3","bar0"].L'ordre n'était pas faux, il était tronqué. Un ordre réellement cassé aurait
rendu l'ordre de la liste (
bar0, bar1, bar2), donc une réponse différente,pas une réponse plus courte.
Le changement
ordreVu()attendaitsleep(560)pour quatre pas de 120 ms — 80 ms demarge. Sur un runner qui fait tourner une dizaine de serveurs en parallèle, le
quatrième pas n'arrive pas à temps.
Le relevé attend désormais la condition (les quatre barres), plafonnée à 3 s
pour rester borné. Il devient indépendant de la vitesse de la machine et ne
ralentit rien sur une machine rapide : 59,2 s contre 59,5 s avant, mesuré.
Pourquoi cet élargissement est sûr
Le
CLAUDE.mdprévient qu'élargir une fenêtre au hasard a déjà fait passer unesuite de 1 à 19 échecs. Ici c'est démontrable : chaque barre n'est retenue qu'à
son premier allumage, donc les cycles suivants du chase sont ignorés.
Attendre plus longtemps ne peut rien ajouter de faux.
Vérifications
npm testnode sync-dist.js --checkdist/synchronelist = [...list]) → la suite tombeAucun changement dans le code livré : un seul fichier de test.
Suite
Cette correction débloque la publication de la 2.1.1, dont tout le reste est
déjà fusionné dans
main.