v0.2.8-pre.007-fix.003

docs/plans/015-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET_PLAN.md

@@ -1,9 +1,9 @@
 <!-- file: docs/plans/015-V0_2_8_HELIUS_LASERSTREAM_WEBSOCKET_PLAN.md -->
-<!-- version: 19 -->
+<!-- version: 20 -->
 
 # Plan `0.2.8` — Helius LaserStream WebSocket
 
-> **Statut : `0.2.8-pre.007-fix.001` corrige le lint et le canari close, mais le replay laisse un seul canari périodique en course scheduler. `0.2.8-pre.007-fix.002` borne l'observation du Ping sans avancer l'horloge virtuelle ; le runtime heartbeat Helius 60 s reste inchangé.**
+> **Statut : `0.2.8-pre.007-fix.002` passe fmt/audit/check/Clippy mais laisse le même unique canari périodique à 330/331. Le diagnostic est affiné : `yield_now()` ne garantit pas la progression du driver I/O OS sous horloge Tokio pausée. `0.2.8-pre.007-fix.003` conserve le runtime heartbeat byte-identical et borne la propagation TCP en temps réel après franchissement du deadline virtuel.**
 
 ## 1. Objet, base et état courant
 
@@ -36,10 +36,11 @@ pre.005-fix.002      suppression warnings dead_code via cfg(test) validée
 pre.006              transactionNotification + lifecycle actor validé
 pre.007              heartbeat Helius WebSocket / idle — checkpoint gate à corriger
 pre.007-fix.001      lint + close canary corrigés ; un canari périodique reste non déterministe
-pre.007-fix.002      observation bornée du Ping après deadline — préparé
+pre.007-fix.002      observation yield-only insuffisante — checkpoint 330/331
+pre.007-fix.003      progression I/O réelle bornée après deadline virtuel — préparé
 
-workspace.package.version courant = 0.2.8-pre.7.fix.2
-commit attendu                    = v0.2.8-pre.007-fix.002
+workspace.package.version courant = 0.2.8-pre.7.fix.3
+commit attendu                    = v0.2.8-pre.007-fix.003
 aucun tag prerelease
 ```
 
@@ -1230,3 +1231,48 @@ Ainsi, le test peut laisser la propagation async finir **sans faire avancer l'ho
 
 Le runtime reste byte-for-byte hors du fix : cadence 60 s, Ping control frame, actor unique, reconnect, shutdown, Config et lifecycle transaction inchangés. `pre.008` reste bloqué jusqu'au replay entièrement vert de `pre.007-fix.002`.
 
+## 18. Replay `pre.007-fix.002` et préparation `pre.007-fix.003`
+
+Checkpoint opérateur `0.2.8-pre.7.fix.2` reçu le 2026-08-23 :
+
+```text
+[x] cargo fmt --all
+[x] python3 scripts/audit_rust_workspace_rules.py = clean / 0 candidate
+[x] cargo check --workspace = vert, sans warning
+[x] cargo clippy --workspace --all-targets = vert, sans warning
+[!] cargo test -p ksp-onchain-transport-lib = 330/331 unit ; même unique canari périodique
+[ ] cargo test --workspace — non retenu tant que Transport n'est pas vert
+```
+
+Le `fix.002` démontre que le problème n'est pas un simple manque de tours scheduler : même 256 `yield_now()` bornés ne rendent pas le Ping observable par la fixture TCP locale. La revue du runtime montre en parallèle que :
+
+```text
+- le deadline heartbeat est construit par `next_helius_heartbeat_deadline()` ;
+- la branche `sleep_until(heartbeat_deadline)` est bien présente dans le `tokio::select!` de l'actor ;
+- un succès de `send_helius_heartbeat()` réarme à `now + 60 s` ;
+- le canari reconnect actor réel continue de prouver un Ping après le réarmement de connexion.
+```
+
+Diagnostic affiné : sous horloge Tokio pausée, `yield_now()` garantit une cession au scheduler mais **ne garantit pas à lui seul un tour du driver I/O OS**. Le chemin d'observation TCP :
+
+```text
+actor -> websocket.send(Ping) -> socket loopback -> reactor I/O -> fixture websocket.next() -> channel
+```
+
+peut donc rester invisible au `try_recv()` malgré un timer actor expiré et une écriture déjà engagée.
+
+`fix.003` reste test-only côté Rust et conserve `src/ws_session.rs` byte-identical. Le canari périodique :
+
+```text
+- garde l'horloge virtuelle pausée pour prouver l'absence avant le deadline ;
+- avance exactement jusqu'au deadline nominal ;
+- reprend ensuite le temps réel uniquement pendant une fenêtre I/O bornée <= 1 s pour laisser le reactor TCP propager le Ping ;
+- repause immédiatement l'horloge après observation ;
+- compense le temps réel consommé avant le contrôle du second intervalle afin de rester strictement avant le second deadline ;
+- franchit ensuite le second deadline avant une nouvelle fenêtre I/O bornée.
+```
+
+Cette fenêtre réelle ne peut pas masquer un heartbeat manquant : elle ne dure qu'une seconde au maximum, très inférieure à l'intervalle provider-owned de 60 s, et n'est ouverte qu'après franchissement du deadline virtuel attendu.
+
+Le runtime, Config, `WsSessionSettings`, le lifecycle transaction et la cadence 60 s restent inchangés. `pre.008` reste bloqué jusqu'au replay entièrement vert de `pre.007-fix.003`.
+