Files
khadhroony-solana-project/deltas/0.1.3/pre.005-fix.001.md

3.3 KiB

Delta 0.1.3-pre.005-fix.001

Base requise

Livraison précédente :

0.1.3-pre.005

Version technique de cette base :

workspace.package.version = "0.1.3-pre.5"
Cargo.toml header version = 45

Validations utilisateur exécutées le 2026-08-15 :

cargo fmt --all                         OK
cargo check --workspace                 OK
cargo clippy --workspace --all-targets  OK
cargo test --workspace                  FAILED — 1 test d'intégration Logging
cargo tree -p ksp-logging-lib            OK
cargo tree -p ksp-logging-lib -d         OK — aucune duplication
cargo tree -p ksp-logging-lib -e features OK

Échec isolé :

global_runtime_supports_takeover_non_blocking_outputs_hot_reload_and_single_initialization
assertion failed: json_text.contains("logging info marker")

Cause

Le test utilisait le même event pour vérifier deux comportements différents :

logging info <ANSI>marker</ANSI>

Cet event était envoyé à la fois au sink Human et au sink Json.

Pour le sink humain, StripAnsiWriter reçoit les octets ANSI bruts après formatage et les supprime, ce qui produit bien :

logging info marker

Pour le formatter JSON, les caractères de contrôle présents dans la valeur structurée sont échappés par le JSON avant l'écriture. La représentation persistée contient donc une forme JSON échappée de l'ESC plutôt qu'une séquence terminal brute ; la sous-chaîne littérale logging info marker n'est alors plus contiguë.

L'échec provenait donc d'une hypothèse incorrecte du test et non d'une perte de l'event par le routing multi-sink.

Correction

Le test d'intégration sépare désormais les responsabilités :

  • LOGGING_TARGET continue de vérifier le sink Human et le stripping ANSI persistant ;
  • un target KSP dédié JSON_KSP_TARGET = "ksp-logging-json-test" alimente le sink JSON ;
  • les events JSON utilisent des messages neutres : json info marker et json error marker ;
  • les assertions JSON vérifient ces marqueurs et le target JSON dédié ;
  • le routing indépendant par target reste ainsi testé explicitement sans dépendre de la représentation d'échappement JSON d'un caractère de contrôle.

Aucun code runtime de ksp-logging-lib n'est modifié.

Version technique

Comme un fichier Rust de test est modifié :

workspace.package.version = "0.1.3-pre.5.fix.1"
Cargo.toml header version = 46
crates/ksp-logging-lib/tests/runtime.rs header version = 7

Fichiers modifiés

Cargo.toml
crates/ksp-logging-lib/tests/runtime.rs

Fichier ajouté

deltas/0.1.3/pre.005-fix.001.md

Hors scope

Ce fix n'ouvre pas pre.006 et ne modifie pas :

  • le runtime multi-sink ;
  • le routing level/target ;
  • le futur routing structuré domain ;
  • Config, JSON Config ou JSON Schema ;
  • les dépendances ou features Cargo.

Validations à exécuter

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

Aucune validation Cargo n'est déclarée réussie tant qu'elle n'a pas été exécutée sur le workspace utilisateur.