v0.3.15-pre.017

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

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-worker-raw-transaction-ingest-lib/USAGE.md -->
-<!-- version: 14 -->
+<!-- version: 15 -->
 
 # Utilisation de ksp-worker-raw-transaction-ingest-lib
 
@@ -232,7 +232,7 @@ La `YellowstoneSubscribeRequest` doit :
 - utiliser explicitement `Confirmed` ou `Finalized` ;
 - rester compatible avec le réseau du `YellowstoneGrpcChannel`.
 
-Le `HttpTransportPool` doit posséder au moins une route compatible avec le rôle d'hydration et `getTransaction` sur le même réseau. La construction de `RawTransactionIngestYellowstoneSource` vérifie ces invariants sans ouvrir la connexion réseau.
+Le `HttpTransportPool` doit posséder au moins une route compatible avec le rôle d'hydration sur le même réseau. Les familles Transaction/TransactionStatus exigent `getTransaction`; un abonnement Yellowstone Block pur exige `getBlock`. La construction de `RawTransactionIngestYellowstoneSource` vérifie ces invariants sans ouvrir la connexion réseau.
 
 Le caller ne passe pas de signature, `program_id`, plage de slots ou limite historique au Worker. Ces paramètres appartiennent à un Job Backfill, pas au service continu.
 
@@ -243,7 +243,7 @@ Les familles productives sont traitées ainsi :
 ```text
 Yellowstone Transaction       -> signal -> HTTP getTransaction -> Common RAW -> admission
 Yellowstone TransactionStatus -> signal -> HTTP getTransaction -> Common RAW -> admission
-Yellowstone Block             -> un signal par transaction -> HTTP getTransaction -> Common RAW -> admission
+Yellowstone Block             -> trigger slot -> HTTP getBlock Full/Base64 -> Common RAW par transaction -> admission
 Standard WS logsSubscribe     -> context.slot + signature -> HTTP getTransaction -> Common RAW -> admission
 Standard WS blockSubscribe    -> Full/Base64 Legacy|V0|V1 -> Common RAW direct par transaction -> admission
 Helius transactionSubscribe   -> Full envelope -> signature/slot/index -> HTTP getTransaction -> Common RAW -> admission
@@ -253,7 +253,7 @@ Yellowstone Slot              -> continuity-only
 Yellowstone Account/Ping/Pong/Entry -> sans RAW Transaction dans cette verticale
 ```
 
-Les signaux de même `(network, signature, commitment)` sont coalescés globalement avant l'hydration HTTP. Si plusieurs sources produisent ensuite la même transaction canonique, le Worker conserve une seule entité RAW et enregistre séparément les observations déterministes propres à chaque source. Le Worker ne possède pas une boucle de retry HTTP : reroutage/retry/backoff restent dans `ksp-onchain-transport-lib`.
+Les signaux de même `(network, signature, commitment)` sont coalescés globalement avant l'hydration HTTP. Si plusieurs sources produisent ensuite la même transaction canonique, le Worker conserve une seule entité RAW et enregistre séparément les observations déterministes propres à chaque source. Pour Yellowstone Block, les slots gRPC sont coordonnés dans une borne pending distincte et plusieurs `getBlock` peuvent progresser jusqu'au quota in-flight de la source ; si l'aval sature, Transport attend de la capacité sur sa queue bornée et propage la backpressure au stream gRPC au lieu de dropper l'update ou de produire un overflow local. Le Worker ne possède pas une boucle de retry HTTP : reroutage/retry/backoff restent dans `ksp-onchain-transport-lib`.
 
 Les sources qui nécessitent `getTransaction` partagent des quotas bornés et déterministes. Pour une composition valide :
 
@@ -266,7 +266,7 @@ somme de leurs tâches d'hydration actives <= persistence_concurrency
 
 Ces contraintes garantissent au moins une part à chaque source reference-bearing sans introduire de scheduler pondéré. Si les settings ne permettent pas cette répartition, le démarrage échoue avant spawn avec `runtime_invalid`; le caller doit augmenter la capacité concernée ou réduire le nombre de sources nécessitant une hydration.
 
-Pour une même identité `(network, signature)`, une divergence canonique de slot, block time, format ou hash est un `content_conflict`. Le Worker ne choisit ni majorité ni provider préféré et n'écrase pas un contenu divergent ; le Store reste l'autorité durable finale du conflit.
+Pour une même identité `(network, signature)`, le Worker ne choisit ni majorité ni provider préféré et n'écrase pas un contenu divergent ; le Store reste l'autorité durable finale. En `0.3.15`, un canonique complet peut accepter comme observation supplémentaire un entrant identique hors `meta.logMessages` lorsque celui-ci contient exactement un marqueur `Log truncated` après un préfixe identique. Le canonique n'est pas réécrit. Le sens tronqué -> complet et toute autre divergence non prouvée restent des `content_conflict` terminaux ; leur stockage en variantes et leur résolution sont réservés à `0.3.16`.
 
 ## Observer le snapshot concret