5.6 KiB
Delta 0.3.15-pre.009
Base
base archive : ksp-general-0.3.15-pre.008-fix.004.zip
base SHA-256 : 206ad2a2a423e8a14a6644877faf0b69b8435e7558aeba6ed3dafff0f16f73a6
base version : 0.3.15-pre.8.fix.4
Le gate opérateur de la base passe les audits Rust/Markdown, cargo check --workspace, Clippy strict, les tests Raw Transaction Ingest Desk et le workspace all-targets/all-features. Les limites live restantes sont traitées comme des propriétés de stratégie/provider et non comme un défaut du lifecycle mono-route de pre.008.
Objectif
Matérialiser le runtime multi-route Mainnet : un Worker indépendant par route, un Store partagé uniquement entre routes du même réseau, Stop ciblé, isolation des faults et réduction du goulet Yellowstone observé avec l'hydration getTransaction unitaire.
Runtime multi-route et Store partagé
Le backend conserve la règle architecturale :
1 route logique = 1 Worker indépendant
N routes same-network = N Workers + 1 Arc<Store> partagé
Le premier Start réserve la route, ouvre le Store et exige Ready. Les Starts suivants du même réseau réutilisent le Store déjà ouvert ; un Start d'un autre réseau est refusé tant que le Store courant reste possédé. Deux Workers de la même identité logique profile_id + route_id ne peuvent pas coexister.
Chaque monitor retire uniquement sa route terminale. Tant qu'un sibling reste actif, le Store reste ouvert. La dernière route terminale reprend l'unique Store, attend la libération des clones Worker, exécute Store::close() puis libère l'identité réseau. Aucun gap, TargetCoverage, processing frontier ou handle Worker n'est partagé entre routes.
stop_route reçoit désormais une identité logique ciblée profile_id + route_id. Un terminal tardif reste idempotent ; si la dernière route a déjà terminé mais que le Store final se ferme encore, Stop attend la fin de ce cleanup sans conserver de MutexGuard à travers un await.
Yellowstone Mainnet : block trigger + reconciliation HTTP
La route stable yellowstone-hydrated conserve son identifiant IPC pour compatibilité mais change de stratégie productive :
AVANT
Yellowstone Transaction/Status/Block
-> une référence transactionnelle
-> getTransaction
-> RAW
PRE.009
Yellowstone Block léger
-> slot
-> getBlock Full/Base64
-> toutes les transactions Legacy/V0/V1 du bloc
-> RAW
Le filtre Yellowstone Block n'embarque pas les transactions dans le payload gRPC ; il sert de trigger temps réel. Le Worker distingue explicitement TransactionHydration et BlockHydration. Le mode block n'entre plus dans la registry globale de getTransaction.
La reconciliation getBlock est interruptible par Stop et retente de façon bornée lorsqu'un bloc n'est pas encore visible ou qu'un endpoint du pool échoue, afin d'absorber le décalage bref entre disponibilité Yellowstone et disponibilité HTTP. Aucune canonicalisation directe protobuf -> RAW n'est revendiquée dans cette tranche.
Pool HTTP Mainnet multi-provider
Le profil publicnode_mainnet expose deux endpoints HTTP sous le même rôle logique default :
PublicNode Mainnet RPC
Solana public Mainnet repair
PublicNode conserve sa concurrence locale sans quota numérique inventé ; Solana public conserve sa limite locale 5 req/s, burst 10. HttpTransportPool garde la sélection par rôle/capability, priorité, health, cooldown et fallback/round-robin entre endpoints éligibles.
Cette tranche prouve le modèle multi-provider sans prétendre qu'un nombre arbitraire d'URLs gratuites garantit une capacité additive stable. D'autres endpoints pourront être ajoutés par Config lorsque leurs capabilities et limites seront connues.
Frontend
La vue Routes conserve le profil réseau sélectionné et permet plusieurs Starts simultanés sur ses routes Configured. Chaque carte possède son Stop ciblé lorsque sa route est active. Le bandeau runtime projette uniquement le nombre de routes actives et leurs identités logiques sûres.
Le monitoring continu des terminaisons spontanées reste pre.010; jusqu'alors, le frontend peut conserver localement le dernier accusé actif jusqu'à un Stop ciblé/resynchronisation.
Frontières conservées
Config : profils, secrets, endpoints et pool multi-provider
Transport : HTTP pool, health/cooldown, WS/gRPC et retry réseau
Worker : stratégie de source, block reconciliation, admission et persistence
Store : idempotence (network, signature) + observations/provenances
Desk : composition de routes, ownership Workers et Store partagé same-network
Aucun partage de gap/frontier entre Workers, aucun Job Backfill automatique, aucun endpoint/secret/URI Store/handle/payload RAW sur IPC.
Version
workspace.package.version : 0.3.15-pre.9
root Cargo header counter : 614
Gate opérateur attendu
cargo fmt --all
cargo fmt --all -- --check
python3 scripts/audit_rust_workspace_rules.py
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas/0.3.15
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test -p ksp-app-raw-transaction-ingest-desk --all-targets --all-features
cargo test -p ksp-worker-raw-transaction-ingest-lib --all-targets --all-features
cargo test --workspace --all-targets --all-features
(cd crates/ksp-app-raw-transaction-ingest-desk && cargo tauri dev)
Aucun script npm applicatif n'est exécuté directement par l'opérateur. cargo tauri build reste réservé au gate final prévu par le plan 0.3.15.