ksp-app-raw-transaction-ingest-desk
Application desktop Tauri KSP destinée à composer et superviser les routes live alimentant le Store commun en RawTransaction.
Le composant conserve les frontières KSP : Config possède les profils/endpoints/secrets, Transport les clients et sessions, Store la persistance et le Worker la logique d'ingestion. Le shell desktop ne déplace jamais ces responsabilités vers le frontend.
Package
package : ksp-app-raw-transaction-ingest-desk
lib : ksp_app_raw_transaction_ingest_desk_lib
bin : ksp-app-raw-transaction-ingest-desk
Frontières
Config -> composite, profils, secrets et résolution effective
Transport -> capabilities HTTP/WS/gRPC et ressources physiques
Desk -> catalogue logique, revalidation Start et ownership du lifecycle mono/multi-route
Store -> persistance via la façade KSP
Worker -> validation des contrats source, acquisition continue et lifecycle d'exécution
L'inventaire de routes est calculé côté Rust à partir du composite Config validé et des settings Transport/Store résolus. Il ne lance aucun probe réseau et n'ouvre ni Store ni Worker.
Au Start, le backend revalide une sélection logique par profile_id + route_id + inventory_generation + commitment. Il recharge Config, reproouve le réseau Store/Transport, reconstruit le pool HTTP ou l'endpoint WS/gRPC exact requis, ouvre le Store via ksp-store-lib, exige un health Ready puis lance le Worker exact via RawTransactionIngestWorker::start_with_runtime_resources. Les ressources physiques et handles restent exclusivement côté Rust.
Le runtime accepte désormais plusieurs routes simultanées sur un même réseau. Chaque route possède son Worker indépendant ; deux Starts de la même identité logique profile_id + route_id sont refusés, et un Start d'un autre réseau est refusé tant que le Store partagé reste ouvert. Le premier Worker ouvre et valide le Store, les suivants réutilisent le même Arc<Store>, puis la dernière route terminale déclenche seule la fermeture explicite du Store. Un fault d'une route ne stoppe pas les Workers siblings. Stop est ciblé par route et reste idempotent lorsqu'un terminal sûr a déjà été retenu.
Les profils applicatifs sont réseau-centriques (devnet, mainnet, testnet). Un profil peut agréger plusieurs profils Transport du même réseau : le provider reste une source de capability et ne devient jamais une identité réseau ni un choix de profil applicatif.
Une route explicitement liée à un provider n’est projetée pour un réseau que si le composite déclare une source Transport de ce provider. Ainsi, la route Helius Transaction existe sur Devnet/Mainnet mais n’est pas présentée sur Testnet tant qu’Helius ne fournit pas de source Testnet configurée.
Le frontend ne reçoit aucune URL, credential, URI Store, metadata secrète, source key, handle runtime ou payload RawTransaction.
Routes V1
yellowstone-hydrated
standard-logs-hydrated
standard-block-direct
helius-transaction-hydrated
http-block-polling
Les profils standard publics committés déclarent Block en plus de Logs; standard-block-direct est donc composable depuis Config sur Devnet, Mainnet et Testnet. Cette déclaration ne transforme pas blockSubscribe en méthode stable et ne remplace pas la revalidation runtime.
Une route Configured est uniquement composable depuis Config. La disponibilité réelle du Store et du Worker est revalidée lors du Start avant publication de l'accusé runtime. Le backend relaie désormais chaque Worker actif par un snapshot latest-value sûr : lifecycle, health, activity, admission/persistence, backpressure, reconnect/replay, continuité, gaps et repair. Les mises à jour sont émises via l'événement Tauri ksp-raw-ingest-route-status et peuvent être resynchronisées avec get_route_monitoring. Les compteurs et slots u64 sont projetés en texte décimal afin de rester exacts côté JavaScript. L'UI détaillée de supervision reste la tranche pre.011.
Pour yellowstone-hydrated, la stratégie Mainnet n'effectue plus un getTransaction par notification transactionnelle. Le Desk construit un abonnement Yellowstone Block léger ; chaque bloc observé déclenche une reconciliation HTTP getBlock Full/Base64 sur le même réseau. Le profil publicnode_mainnet expose un pool HTTP logique default contenant PublicNode et le RPC public Solana comme fallback de même priorité. Le pool conserve les limites propres à chaque endpoint, son health/cooldown et son round-robin interne. La reconciliation Yellowstone tolère un décalage bref entre le gRPC et les RPC HTTP grâce à un retry borné et interruptible par Stop. Le chemin protobuf -> RAW direct reste différé tant que la canonicalisation exacte du meta n'est pas prouvée pour toutes les formes supportées.
Ports de développement
Vite HTTP : 1440
Vite WS : 1441
Lancement :
(cd crates/ksp-app-raw-transaction-ingest-desk && cargo tauri dev)
Le cycle frontend est déclenché par Tauri via ses hooks configurés ; les scripts npm applicatifs ne sont pas lancés directement par l'opérateur.
Voir USAGE.md et ../../docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md.