Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.2.9-pre.002-fix.002

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-24 11:00:38 +02:00
parent 61fba107ef
commit 3172cda241
4 changed files with 30 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md
View File

@@ -1,9 +1,9 @@
<!-- file: docs/plans/016-V0_2_9_YELLOWSTONE_GRPC_PLAN.md -->
<!-- version: 6 -->
<!-- version: 7 -->
# Plan `0.2.9` — moteur Yellowstone gRPC + standard Solana + PublicNode
> **Statut : `0.2.9-pre.002-fix.001` — correctif technique du premier gate opérateur : le channel lazy est conservé comme état N1 de production, `prepare()` refuse proprement l’absence de runtime Tokio au lieu de laisser Tonic paniquer, et les canaries Clippy/runtime sont corrigés. Les gates Cargo doivent être réexécutés après ce fix avant commit. `0.2.9` reste bornée à un moteur client Yellowstone partagé, une façade Solana Yellowstone standard et une première intégration concrète PublicNode. Seuls OrbitFlare puis Helius LaserStream gRPC sont actuellement planifiés comme releases provider suivantes ; les autres providers restent en TODO/IDEAS sans numéro réservé. Chaque prerelease vise 15–20 minutes de travail effectif et la release complète doit rester clôturable dans une seule session de chat.**
> **Statut : `0.2.9-pre.002-fix.002` — second correctif du gate opérateur : `fix.001` est confirmé vert sur fmt/audit/check/Clippy et les 346 unit tests ; seul le canari d’intégration `public_api` appelait encore le channel lazy depuis un test synchrone. `fix.002` place ce canari sous runtime Tokio sans modifier N1 en production. Les tests Transport/workspace doivent être réexécutés avant commit. `0.2.9` reste bornée à un moteur client Yellowstone partagé, une façade Solana Yellowstone standard et une première intégration concrète PublicNode. Seuls OrbitFlare puis Helius LaserStream gRPC sont actuellement planifiés comme releases provider suivantes ; les autres providers restent en TODO/IDEAS sans numéro réservé. Chaque prerelease vise 15–20 minutes de travail effectif et la release complète doit rester clôturable dans une seule session de chat.**
## 1. Objet, base et état d'ouverture
@@ -897,8 +897,8 @@ Prévision courante :
pre.001 DONE — audit upstream/service/proto + providers gratuits + licences/deps + architecture + threat model + sizing
budget : 15–20 min nominal ; preuve : plan + matrice + stratégie B + forecast recalibré
pre.002 FIX.001 CANDIDATE — moteur Yellowstone : proto/dependencies + settings/errors + channel minimal
budget : 15–20 min ; premier gate : fmt/audit/check PASS, Clippy/test ont révélé return implicite + runtime Tokio ; fix appliqué ; cargo tree inspecté
pre.002 FIX.002 CANDIDATE — moteur Yellowstone : proto/dependencies + settings/errors + channel minimal
budget : 15–20 min ; second gate : fmt/audit/check/Clippy + 346 unit PASS ; public_api sync corrigé sous Tokio ; cargo tree inspecté
pre.003 moteur Yellowstone : TLS/metadata générique + fixture locale + 7 unary RPCs
budget : 15–20 min ; preuve : connect/TLS/timeouts/Status safe + wire unary exact