v0.3.15-pre.008-fix.004
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md -->
|
||||
<!-- version: 11 -->
|
||||
<!-- version: 12 -->
|
||||
|
||||
# Plan v0.3.15 — Raw Transaction Ingest Desk
|
||||
|
||||
@@ -791,13 +791,21 @@ Stop
|
||||
|
||||
Le slot reste occupé pendant le drain terminal et la fermeture Store ; aucun second Start n'est admis durant cette fenêtre. Le frontend ne reçoit ni `WorkerId`, ni handle, ni endpoint, ni URI Store. La terminaison spontanée est nettoyée backend-side mais son streaming vers le frontend reste `pre.010`. Le partage d'un même Store entre plusieurs Workers reste `pre.009`.
|
||||
|
||||
#### `pre.008-fix.004` — cohérence de source Yellowstone Mainnet
|
||||
|
||||
Le test live Mainnet a montré que `yellowstone-hydrated` ouvrait bien le gRPC PublicNode mais reconstruisait son pool `getTransaction` à partir du Transport de base `mainnet_public`, donc `api.mainnet.solana.com`. Le fix impose que le gRPC Yellowstone et son hydration HTTP proviennent du même composant `transport.yellowstone`. Le profil `publicnode_mainnet` utilise désormais `https://solana-rpc.publicnode.com` pour son endpoint HTTP et n'hérite plus de la limite locale Solana-public `5 req/s`; la concurrence reste bornée et les `429` continuent à déclencher le cooldown Transport.
|
||||
|
||||
Ce fix ne prétend pas rendre viable le firehose Mainnet complet par hydration unitaire. La suppression de l'hydration systématique quand Yellowstone porte déjà le matériau transactionnel, le pool HTTP multi-provider, le multi-route, la déduplication cross-route et le repair HTTP par bloc sont explicitement déplacés vers `pre.009`.
|
||||
|
||||
Budget cible : une tranche runtime mono-route.
|
||||
|
||||
### `pre.009` — multi-route et Store partagé
|
||||
### `pre.009` — optimisation Mainnet, multi-route et Store partagé
|
||||
|
||||
Permettre plusieurs routes simultanées avec un Worker indépendant par route, un même Store partagé lorsque le réseau est strictement identique et une isolation des faults entre routes.
|
||||
Permettre plusieurs routes simultanées avec un Worker indépendant par route, un même Store partagé lorsque le réseau est strictement identique et une isolation des faults entre routes. La tranche doit également traiter le goulet observé sur Mainnet : privilégier un chemin Yellowstone direct lorsque le matériau RAW peut être reconstruit sans `getTransaction`, réserver HTTP à la réparation/hydration réellement nécessaire, et introduire un pool HTTP multi-provider dont les quotas, health, cooldown et capabilities restent endpoint-owned.
|
||||
|
||||
Budget cible : une tranche runtime multi-route.
|
||||
Le Store conserve l'idempotence `(network, signature)` et les observations/provenances permettent à plusieurs routes de confirmer la même transaction sans créer une seconde entité RAW. Le repair HTTP doit privilégier le niveau bloc lorsqu'il permet de récupérer plusieurs transactions par requête.
|
||||
|
||||
Budget cible : une tranche runtime/throughput Mainnet + multi-route.
|
||||
|
||||
### `pre.010` — snapshots et monitoring runtime
|
||||
|
||||
|
||||
Reference in New Issue
Block a user