69 lines
4.0 KiB
Markdown
69 lines
4.0 KiB
Markdown
<!-- file: crates/ksp-app-raw-transaction-ingest-desk/README.md -->
|
||
<!-- version: 7 -->
|
||
|
||
# `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
|
||
|
||
```text
|
||
package : ksp-app-raw-transaction-ingest-desk
|
||
lib : ksp_app_raw_transaction_ingest_desk_lib
|
||
bin : ksp-app-raw-transaction-ingest-desk
|
||
```
|
||
|
||
## Frontières
|
||
|
||
```text
|
||
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 est actuellement mono-route : un seul Start peut posséder le slot applicatif. Le handle Worker est installé avant l'accusé Start. Stop demande un arrêt coopératif, attend le terminal Worker, puis le monitor backend reprend l'unique `Arc<Store>` et exécute `Store::close()` avant de libérer le slot. Le partage d'un Store entre plusieurs Workers reste une responsabilité de la tranche multi-route suivante.
|
||
|
||
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
|
||
|
||
```text
|
||
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. Les états spontanés après Start ne sont pas encore streamés vers le frontend ; l'observabilité continue est ajoutée par la tranche monitoring dédiée.
|
||
|
||
## Ports de développement
|
||
|
||
```text
|
||
Vite HTTP : 1440
|
||
Vite WS : 1441
|
||
```
|
||
|
||
Lancement :
|
||
|
||
```bash
|
||
(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`](USAGE.md) et [`../../docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md`](../../docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md).
|