v0.3.15-pre.008-fix.004

This commit is contained in:
2026-09-14 09:24:27 +02:00
parent 11e5247fbf
commit d3eea1aa12
11 changed files with 110 additions and 25 deletions

View File

@@ -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