Montées Dependabot : golang-x et SQLite, avec la couverture qui manquait au LogStore - #17
Merged
Conversation
golang.org/x/crypto v0.53.0 -> v0.56.0 (Argon2id du chiffrement au repos), golang.org/x/mod v0.38.0 -> v0.40.0 (comparaison semver de l'updater), et par transitivité x/net v0.56.0 -> v0.57.0 et x/text v0.39.0 -> v0.41.0. Reprend la PR Dependabot #11. Groupés en une seule montée parce que ces paquets avancent ensemble : des PR séparées se cassent mutuellement la CI sur le go.sum.
… valident Reprend la PR Dependabot #12. Entraîne modernc.org/libc 1.70.0 -> 1.75.6, modernc.org/memory 1.11.0 -> 1.12.1 et github.com/mattn/go-isatty 0.0.20 -> 0.0.24. Pourquoi des tests arrivent avec un bump de dépendance ------------------------------------------------------ logstore.go était à 0 % de couverture : aucun test ne construisait un LogStore, donc rien n'exerçait SQLite. Le paquet storage affichait pourtant 31,9 %, parce que ses tests couvraient la configuration, le chiffrement et le magasin de CA — tout sauf le moteur. Monter le pilote de la base de dix versions mineures sur cette base-là aurait été un changement non vérifié sur le composant qui persiste l'intégralité des journaux. Les tests ajoutés passent par le vrai moteur plutôt que de le simuler, et couvrent ce que le bump pouvait casser : schéma et aller-retour des colonnes, INSERT OR IGNORE sur clé primaire textuelle, filtres, les trois modes de recherche (FTS5 en mode texte échappé, FTS5 brut avec opérateurs, regex post-requête en Go), tri et pagination, groupement, rétention par âge et par nombre, statistiques, VACUUM, et le cycle complet de chiffrement au repos — fermeture qui chiffre et supprime le clair, réouverture verrouillée, refus du mauvais mot de passe, déverrouillage et intégrité des lignes. Deux comportements défensifs sont vérifiés au passage : un champ de tri absent de l'allowlist retombe sur timestamp au lieu d'atteindre le SQL, et une requête FTS5 malformée renvoie zéro ligne au lieu de faire tomber le processus. Couverture du paquet storage : 31,9 % -> 76,9 %. maxWriteBuffer devient une variable ----------------------------------- Vérifier le plafond du tampon d'écriture à sa valeur de production veut dire mettre 200 000 messages en file et laisser la boucle de flush les écrire : dix minutes sous le détecteur de course, pour une branche de trois lignes. La constante devient une variable que le test abaisse le temps de s'exécuter. Le test était aussi non déterministe dans sa première forme — la boucle de flush vidait le tampon en parallèle de son remplissage — et porte désormais sur le compteur de pertes, qui est ce qui rend l'abandon visible dans StorageStats.
This was referenced Sep 5, 2026
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
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.
Reprend les PR Dependabot #11 et #12 en deux commits bissectables, testés sur le
mainactuel — les originales étaient construites sur la base d'avant Svelte 5et Node 22.
#11 — groupe golang-x
golang.org/x/crypto0.53.0 → 0.56.0 (Argon2id du chiffrement au repos),golang.org/x/mod0.38.0 → 0.40.0 (comparaison semver de l'updater), et partransitivité
x/net0.56.0 → 0.57.0,x/text0.39.0 → 0.41.0.#12 — modernc.org/sqlite 1.48.1 → 1.58.0
Entraîne
modernc.org/libc1.70.0 → 1.75.6,modernc.org/memory1.11.0 → 1.12.1et
github.com/mattn/go-isatty0.0.20 → 0.0.24.Pourquoi des tests arrivent avec un bump de dépendance
En voulant valider ce bump, j'ai trouvé que
logstore.goétait à 0 % decouverture : aucun test ne construisait un
LogStore, donc rien n'exerçaitSQLite. Le paquet
storageaffichait pourtant 31,9 %, parce que ses testscouvraient la configuration, le chiffrement et le magasin de CA — tout sauf le
moteur. Monter le pilote de dix versions mineures sur cette base aurait été un
changement non vérifié sur le composant qui persiste l'intégralité des journaux.
Les tests ajoutés passent par le vrai moteur plutôt que de le simuler, et
couvrent ce que le bump pouvait casser :
en texte RFC3339Nano ;
INSERT OR IGNOREsur clé primaire textuelle (un lot rejoué ne double pas) ;opérateurs, et regex post-requête en Go ;
VACUUM,ClearAll;le clair, réouverture verrouillée, refus du mauvais mot de passe,
déverrouillage et intégrité des lignes.
Deux comportements défensifs sont vérifiés au passage : un champ de tri absent de
l'allowlist retombe sur
timestampau lieu d'atteindre le SQL, et une requêteFTS5 malformée renvoie zéro ligne au lieu de faire tomber le processus.
Couverture du paquet
storage: 31,9 % → 76,9 %.logstore.gopasse de 0 %à environ 81 % en moyenne par fonction.
maxWriteBufferdevient une variableVérifier le plafond du tampon d'écriture à sa valeur de production veut dire
mettre 200 000 messages en file et laisser la boucle de flush les écrire : dix
minutes sous
-racepour une branche de trois lignes — je l'ai mesuré enécrivant la première version du test. La constante devient une variable que le
test abaisse le temps de s'exécuter.
Ce test était aussi non déterministe dans sa première forme : la boucle de flush
vidait le tampon en parallèle de son remplissage. Il porte désormais sur le
compteur de pertes, qui est ce qui rend l'abandon visible dans
StorageStats.Les trois autres PR Dependabot
#13, #14 et #15 ont été fermées : elles sont caduques depuis la migration Svelte 5.
#15 proposait les mêmes montées que la #16 sans les changements de code
qu'elles exigent, et #13/#14 visaient des versions que le lockfile régénéré
dépasse déjà.