technova69/spip-check
Par gilles, le 3 septembre 2026 à 00h30min :
fix: borner et rendre rejouable la classification
Trois garde-fous du run store, a la taille de lot actuelle. Ils sont la
condition prealable a toute consolidation des lots : elargir un lot sans
eux multiplie d’autant la fenetre de perte et le cout quadratique.
- classifyBatch() accepte un budget de 2 secondes, comme indexBatch() et
scanBatch() en avaient deja un. Le controle a lieu apres l’enregistrement
d’une entree, jamais avant : un lot rend toujours au moins une entree,
sans quoi l’etape se rappellerait indefiniment sans avancer. Le corps de
boucle est extrait dans classifyRecord() pour que les sorties anticipees
ne court-circuitent plus le controle du budget. - appendCandidate() refuse tout identifiant deja atteint. Les candidats
etant inscrits par identifiants croissants, une borne haute suffit a
rendre l’inscription idempotente, sans index ni relecture par appel. Une
requete interrompue avant d’avoir persiste son classify_after est des
lors rejouable sans dupliquer le journal ni gonfler le compteur. - appendFinding() consulte un index en memoire au lieu de relire
findings.jsonl a chaque appel. Invalidation sur la taille du journal, et
explicite a chaque reecriture : une reecriture de meme taille ne doit pas
passer inapercue.
Mesure sur 1500 scripts hostiles deposes dans IMG/, le cas que l’outil
vise : 1246 ms avant, 70 ms apres, pour des constats identiques.
Modifié
CHANGELOG.md
spip-check.php
src/SpipCheck.php
tests/unit/IndexedScannerTest.php
tests/unit/RunStoreTest.php
Détails : https://git.spip.net/technova69/spip-check/-/commit/398f17c987d6ad45d619767f7f82f4d17b31747b