v0.3.15-pre.017

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

@@ -1,5 +1,5 @@
 <!-- file: crates/ksp-worker-raw-transaction-ingest-lib/README.md -->
-<!-- version: 16 -->
+<!-- version: 17 -->
 
 # ksp-worker-raw-transaction-ingest-lib
 
@@ -169,7 +169,7 @@ Le Worker s'exécute sur le runtime Tokio courant du caller. Il ne crée pas de
 - utiliser la même source via `WorkerSnapshotSource` ;
 - attendre le terminal après drain et join des tâches possédées.
 
-Le shutdown est borné par `shutdown_drain_timeout` (10 s par défaut). Le supervisor multi-source relaie le stop à toutes les sources et les rejoint avant de rendre son résultat au supervisor Worker ; les tâches source, hydration et persistence possédées sont ensuite drainées ou abort+join avant publication terminale. Si la deadline expire, l'abort du wrapper source détruit aussi son `JoinSet` interne et annule ses tâches imbriquées avant le terminal. Une faute déjà observée n'est pas remplacée par un stop concurrent, sauf le `drain_timeout` terminal lorsqu'une récupération bornée dépasse sa deadline. Pour Yellowstone, un timeout de fermeture Transport survenant après un Stop déjà demandé est traité comme une fermeture coopérative : `SolanaYellowstoneGrpcSubscribeSession::close()` a déjà aborté puis joint son acteur avant de retourner ce timeout. Les autres erreurs de fermeture restent terminales. L'abandon terminal d'une hydration retire son pending run-local sans le convertir artificiellement en travail `settled`.
+Le shutdown est borné par `shutdown_drain_timeout` (10 s par défaut). Le supervisor multi-source relaie le stop à toutes les sources et les rejoint avant de rendre son résultat au supervisor Worker ; les tâches source, hydration et persistence possédées sont ensuite drainées ou abort+join avant publication terminale. Si la deadline expire, l'abort du wrapper source détruit aussi son `JoinSet` interne et annule ses tâches imbriquées avant le terminal. Une faute déjà observée n'est pas remplacée par un stop concurrent, sauf le `drain_timeout` terminal lorsqu'une récupération bornée dépasse sa deadline. Pour Yellowstone, un `Status` distant reçu après le half-close local explicitement engagé est classé `Closed` par Transport et ne remplace plus le Stop coopératif ; un timeout de fermeture Transport survenant après un Stop déjà demandé reste lui aussi accepté par le Worker comme fermeture coopérative bornée. En revanche, un `grpc_status` observé pendant une session active conserve la politique normale reconnect/failure. L'abandon terminal d'une hydration retire son pending run-local sans le convertir artificiellement en travail `settled`.
 
 ## Admission, coalescence et backpressure
 
@@ -187,7 +187,7 @@ source hydratante active => quota pending >= 1 et quota in-flight >= 1
 
 Pour garantir simultanément ces bornes et l'absence de starvation structurelle, le démarrage échoue avant spawn si le nombre de sources hydratantes dépasse `admission_queue_capacity` ou `persistence_concurrency`. Le registre des hydrations transactionnelles protège en plus l'ouverture effective des `getTransaction`; Yellowstone Block reste borné par sa partition déterministe et son `JoinSet` possédé.
 
-Les signaux partageant le même `(network, signature, commitment)` sont coalescés cross-source avant le fan-out HTTP. La publication du résultat partagé notifie les followers sous le verrou de registry avant de retirer la clé : une nouvelle génération de leader ne peut donc pas s'intercaler entre retrait et notification. Après canonicalisation, une cache run-local bornée sérialise les acquisitions de même `(network, signature)` : la première passe par l'écriture atomique entity + observation, les suivantes de contenu canonique identique ajoutent uniquement leur observation déterministe. Une divergence de slot, block time, format ou hash canonique devient un content conflict terminal ; aucune majorité, préférence provider ou overwrite n'est appliqué. Le Store conserve son guard durable final.
+Les signaux partageant le même `(network, signature, commitment)` sont coalescés cross-source avant le fan-out HTTP. La publication du résultat partagé notifie les followers sous le verrou de registry avant de retirer la clé : une nouvelle génération de leader ne peut donc pas s'intercaler entre retrait et notification. Après canonicalisation, une cache run-local bornée sérialise les acquisitions de même `(network, signature)` : la première passe par l'écriture atomique entity + observation, les suivantes de contenu canonique identique ajoutent uniquement leur observation déterministe. Le Store conserve le guard durable final. En `0.3.15`, il accepte aussi un entrant strictement moins complet lorsque l'unique divergence prouvée est `meta.logMessages` avec exactement un marqueur `Log truncated` après un préfixe identique alors que le canonique stocké n'est pas tronqué ; le canonique complet reste inchangé et l'observation est conservée. Toute autre divergence, ainsi que le sens tronqué -> complet, reste un `content_conflict` terminal. Aucune majorité, préférence provider ou overwrite n'est appliqué.
 
 Les retries/reroutages HTTP appartiennent à `ksp-onchain-transport-lib`. Le Worker ne possède pas une seconde boucle de retry autour de `getTransaction`.
 
@@ -287,7 +287,7 @@ content conflict
 store failure
 ```
 
-Un content conflict est terminal et n'est jamais converti en succès idempotent.
+Un content conflict réel reste terminal en `0.3.15` et n'est jamais converti en succès idempotent. L'exception `logMessages` tronqués décrite ci-dessus est classée avant le conflit comme observation compatible moins complète ; elle ne remplace pas le canonique et n'incrémente pas le terminal `content_conflict`. La conservation de variantes conflictuelles et leur résolution sans arrêt du Worker appartiennent à `0.3.16`.
 
 ## Snapshots et erreurs
 

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