khadhroony-solana-project/deltas/0.1.2/pre.005.md

Delta 0.1.2-pre.005

Identité

0.1.2-pre.005 — intégration, concurrence, saturation et audits Logging

Version Cargo portée par ce delta :

0.1.2-pre.5

Base

Base directe : 0.1.2-pre.004-fix.004, version Cargo 0.1.2-pre.4.fix.4.

La validation utilisateur de cette base a exécuté avec succès :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test --workspace

Le test runtime global passe alors avec takeover des targets externes, console/fichier non bloquants, stripping ANSI, lifecycle des WorkerGuard et hot reload.

Mission du delta

Cette tranche ne modifie pas la surface fonctionnelle publique de Logging. Elle durcit la fondation existante avant la validation finale :

• saturation déterministe des queues lossy ;
• émissions concurrentes pendant hot reload ;
• vérification des temps de lifecycle de spans ;
• audit automatique du takeover de dépendances ;
• documentation consommateur de la crate ;
• probe diagnostic de l'overhead du mécanisme reload.

Changements Rust

Construction non bloquante testable sans setting supplémentaire

runtime.rs centralise la construction du NonBlockingBuilder dans un helper privé utilisé par la production.

La politique reste :

lossy = true

La taille de queue n'entre pas dans LoggingSettings. Le test unitaire peut cependant dériver le même builder avec buffered_lines_limit(1) afin de provoquer une saturation contrôlée.

Saturation déterministe

Le test unitaire runtime introduit un writer qui bloque volontairement son worker sur la première écriture.

Une fois le worker bloqué :

1. la queue est limitée à une ligne ;
2. un producteur émet 1024 lignes supplémentaires ;
3. le producteur doit terminer sous timeout alors que le writer reste bloqué ;
4. le compteur ErrorCounter::dropped_lines() doit être strictement positif ;
5. le writer est ensuite libéré et le WorkerGuard peut terminer proprement.

Ce test distingue directement la politique lossy retenue d'une régression vers une queue exerçant de la backpressure.

Concurrence pendant hot reload

Le test runtime global lance quatre threads qui émettent continuellement via ksp_logging_lib::trace! pendant que le thread possédant LoggingGuard effectue 32 reinitialize() successifs.

Les settings alternent entre :

• runtime sans sink ;
• console non bloquante présente avec niveau KSP Off.

Le test exerce donc le reload, la création/retrait de worker guards et la lecture concurrente du subscriber sans inonder stdout/stderr.

Lifecycle des spans

Un nouveau test avec subscriber local vérifie que FmtSpan::NEW | FmtSpan::CLOSE produit pour un span KSP :

• l'identité du span ;
• l'événement new ;
• l'événement close ;
• time.busy ;
• time.idle.

Audit de takeover

tests/ownership.rs parcourt les crates du workspace autres que ksp-logging-lib et rejette :

• une dépendance Cargo directe tracing ;
• une dépendance directe tracing-subscriber ;
• une dépendance directe tracing-appender ;
• les usages Rust directs tracing::, tracing_subscriber:: ou tracing_appender::.

La crate Logging elle-même est explicitement exclue de cet audit car elle possède légitimement la stack.

Documentation de crate

Ajouts :

crates/ksp-logging-lib/README.md
crates/ksp-logging-lib/USAGE.md
crates/ksp-logging-lib/TODO.md

Ils documentent notamment :

• target = nom Cargo de la crate propriétaire ;
• champs structurés additionnels ;
• initialize puis reinitialize ;
• hot reload transactionnel ;
• spans sync/async ;
• dropped lines ;
• capacités explicitement différées.

Probe d'overhead

tests/overhead.rs est ignoré par défaut car il s'agit d'un probe temporel diagnostic, pas d'un benchmark de précision.

Commande explicite :

cargo test -p ksp-logging-lib --test overhead -- --ignored --nocapture

Le probe compare un filtre local fixe au même filtre derrière tracing_subscriber::reload::Layer sur 200000 événements et n'échoue que si le coût reload dépasse un garde-fou volontairement très large. Le résultat sert à repérer une régression grossière ; il ne constitue pas une mesure HFT ni un engagement de performance absolue.

Audit des dépendances

Aucune dépendance n'est ajoutée par pre.005.

Lors de pre.004, les commandes utilisateur ont observé :

tracing             0.1.44
tracing-subscriber  0.3.23
tracing-appender    0.2.5

cargo tree -p ksp-logging-lib -d ne signalait aucun doublon. Le graphe de features n'activait pas via KSP tracing-attributes, tracing-log, env-filter, JSON/Serde ou le formatter ANSI. Ces commandes doivent être réexécutées sur pre.005 avant validation finale de la tranche car une validation d'une base précédente ne vaut pas validation du delta courant.

Validations à exécuter

Non exécutées dans l'environnement de génération :

cargo fmt --all
cargo check --workspace
cargo test --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-logging-lib --test overhead -- --ignored --nocapture
cargo tree -p ksp-logging-lib
cargo tree -p ksp-logging-lib -d
cargo tree -p ksp-logging-lib -e features

La base stable ne contient pas de répertoire scripts/; aucun script inexistant n'est déclaré réussi.

Suite

Après validation de pre.005, la tranche prévue est :

0.1.2-pre.006 — validation finale, documentation, cleanup et prompt 0.1.3