v0.3.13-pre.006

crates/ksp-worker-raw-transaction-ingest-lib/README.md

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-worker-raw-transaction-ingest-lib/README.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # ksp-worker-raw-transaction-ingest-lib
 
@@ -13,7 +13,7 @@ RawTransactionIngestWorker::start
 
 RawTransactionIngestWorker::start_with_runtime_resources
     -> même runtime + une source productive supervisée
-       Yellowstone, WS standard logsSubscribe, WS standard blockSubscribe ou Helius transactionSubscribe
+       Yellowstone, WS standard logsSubscribe, WS standard blockSubscribe, Helius transactionSubscribe ou HTTP block polling
        + hydration HTTP getTransaction lorsque la source produit une référence
 ```
 
@@ -45,6 +45,12 @@ Helius transactionSubscribe
     -> coalescence bornée par (network, signature, commitment)
     -> HTTP getTransaction observed avant Common RAW
 
+Solana HTTP live block polling
+    -> getSlot borne le run courant
+    -> getBlocksWithLimit découvre les blocs live
+    -> getBlock observed matérialise Full/Base64 Legacy/V0/V1
+    -> matériau Common RAW direct par transaction du bloc
+
 les chemins productifs
     -> ksp-raw-transaction-lib
     -> admission centrale bornée
@@ -76,7 +82,7 @@ La construction est sans I/O et refuse notamment :
 - une provenance provider/endpoint non représentable ;
 - l'absence d'une route HTTP compatible pour `getTransaction` sur le même réseau.
 
-Le runtime-resource aggregate public accepte une collection validée de 1 à 32 sources logiques. `pre.005` sait exécuter une source unique Yellowstone, Standard Logs, Standard Block ou Helius Transaction ; une activation simultanée de plusieurs sources reste rejetée avant spawn jusqu'au supervisor dédié. La collection interne, les `source_key`, les URLs, les filtres et les clients inférieurs ne sont pas exposés.
+Le runtime-resource aggregate public accepte une collection validée de 1 à 32 sources logiques. `pre.006` sait exécuter une source unique Yellowstone, Standard Logs, Standard Block, Helius Transaction ou HTTP Block Polling ; une activation simultanée de plusieurs sources reste rejetée avant spawn jusqu'au supervisor dédié. La collection interne, les `source_key`, les URLs, les filtres et les clients inférieurs ne sont pas exposés.
 
 ## Contrat de source Standard Logs + HTTP
 
@@ -128,6 +134,22 @@ Au runtime, `HeliusLaserStreamWsSession::connect` puis `transaction_subscribe` s
 
 La clé logique Helius inclut réseau, identités provider/endpoint sûres, commitment et empreinte privée du filtre. Les listes de pubkeys du filtre sont normalisées avant hash afin que leur ordre ne crée pas artificiellement deux sources logiques ; le rôle HTTP d'hydration reste exclu de l'identité live.
 
+## Contrat de source HTTP Block Polling
+
+`RawTransactionIngestHttpBlockPollingSource::new` reçoit :
+
+```text
+HttpTransportPool
+HttpRoleName de polling
+SolanaCommitment Confirmed ou Finalized
+```
+
+La construction est sans I/O et vérifie que le rôle HTTP possède, sur un seul réseau, les capacités `getSlot`, `getBlocksWithLimit` et `getBlock`. La cadence est bornée entre 100 ms et 30 s, avec 1 s par défaut ; la découverte est bornée entre 1 et 1024 blocs par cycle, avec 128 par défaut. Ces réglages de cadence ne font pas partie de l'identité logique de la source.
+
+Au démarrage, le premier `getSlot` fixe la borne inférieure du run. Le Worker ne demande aucun slot antérieur. Chaque cycle relit le tip, découvre les blocs disponibles avec `getBlocksWithLimit`, puis matérialise chaque slot listé par `getBlock observed` en `Full + Base64 + maxSupportedTransactionVersion = 1 + showRewards = false`. Seules les transactions Legacy/V0/V1 explicitement qualifiées entrent directement dans Common RAW.
+
+Un slot listé dont `getBlock` retourne `null` reste la tête de reprise du cycle suivant ; il n'est ni considéré vide ni marqué settled. Les slots absents de la liste de découverte sont traités comme non produits/skipped pour ce run. Le slot n'est settled qu'après admission réussie de toutes ses transactions. Le polling reste run-local : aucun checkpoint durable, aucun scan avant la borne initiale et aucun Backfill implicite ne sont créés. Les retries/reroutages HTTP restent possédés par `ksp-onchain-transport-lib`.
+
 ## Runtime et lifecycle
 
 Le Worker s'exécute sur le runtime Tokio courant du caller. Il ne crée pas de runtime global et n'expose aucun `JoinHandle` public.
@@ -264,7 +286,6 @@ La crate ne dépend pas de Config, Job, `ksp-store-api` directement, backend Sto
 La verticale actuelle ne possède pas :
 
 - plusieurs sources productives simultanées dans `RawTransactionIngestRuntimeResources` ;
-- source HTTP live polling Worker ;
 - sélection Config interne au Worker ;
 - checkpoint persistent de processing frontier ;
 - campagne de réparation historique automatique ;