v0.3.15-pre.008-fix.004
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md -->
|
||||
<!-- version: 12 -->
|
||||
<!-- version: 13 -->
|
||||
|
||||
# Validation v0.3.15 — Raw Transaction Ingest Desk
|
||||
|
||||
@@ -413,9 +413,17 @@ Surface IPC sûre ajoutée : `start_route` et `stop_route`, avec `RawIngestRoute
|
||||
|
||||
Le frontend fournit un contrôle minimal Start/Stop mono-route et le choix `confirmed`/`finalized`. Il ne prétend pas encore fournir le monitoring continu : une terminaison spontanée est nettoyée backend-side mais sa projection temps réel demeure `pre.010`. Multi-route, Store partagé entre Workers et isolation inter-route demeurent `pre.009`.
|
||||
|
||||
### `pre.009` — runtime multi-route
|
||||
#### `pre.008-fix.004` — preuve live Mainnet et correction PublicNode
|
||||
|
||||
Un Worker par route, même Store si réseau identique, isolation des faults.
|
||||
Le parcours live `pre.008-fix.003` prouve que le channel Yellowstone PublicNode Mainnet s'ouvre et produit des transactions, mais que l'hydration était construite depuis le Transport de base `mainnet_public`. Les traces montraient donc le gRPC `publicnode_solana_mainnet_yellowstone` suivi de requêtes `getTransaction` via `solana_mainnet_public`, puis rate-limit/cooldown et overflow de queue.
|
||||
|
||||
Le fix corrige la composition : `prepare_yellowstone` prend désormais son role/pool HTTP dans le même `ResolvedTransportConfig` optionnel qui fournit le gRPC. Le profil `publicnode_mainnet` expose `publicnode_solana_mainnet_rpc` sur `https://solana-rpc.publicnode.com`, provider `publicnode`, sans recopier la limite locale `5 req/s` du profil Solana-public. La concurrence locale reste bornée à 8 et le cooldown Transport sur `429` reste actif.
|
||||
|
||||
Non-claim : ce changement réduit une erreur de composition mais ne garantit pas qu'une hydration HTTP unitaire puisse suivre le firehose Mainnet. L'optimisation structurelle Yellowstone direct + pool HTTP multi-provider + repair bloc est reportée à `pre.009`.
|
||||
|
||||
### `pre.009` — optimisation Mainnet et runtime multi-route
|
||||
|
||||
Un Worker par route, même Store si réseau identique, isolation des faults, chemin Yellowstone direct lorsque possible, pool HTTP multi-provider et repair par bloc pour éviter que `getTransaction` unitaire soit le chemin nominal du temps réel.
|
||||
|
||||
### `pre.010` — monitoring
|
||||
|
||||
|
||||
Reference in New Issue
Block a user