0.3.15-pre.014-fix.002

docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md

@@ -1,5 +1,5 @@
 <!-- file: docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md -->
-<!-- version: 29 -->
+<!-- version: 30 -->
 
 # Validation v0.3.15 — Raw Transaction Ingest Desk
 
@@ -986,3 +986,14 @@ canonique déjà complet
 Le canonical RAW n'est jamais remplacé par la version tronquée. Les cas suivants restent des `content_conflict` en `0.3.15` : préfixe différent avant le marqueur, autre champ `meta` différent, marqueur non exact ou multiple, canonique déjà tronqué puis version plus complète entrante. Ce dernier cas nécessite une promotion canonique atomique et appartient explicitement à `0.3.16`, avec variantes durables et historique de résolution ; il n'est pas simulé par un overwrite opportuniste dans ce fix.
 
 Le correctif ne change aucune API publique Store/Worker, aucun schema SQL et aucun outcome public. `RawEntityWriteOutcome::AlreadyPresent` reste l'outcome canonique, l'observation entrante est conservée normalement et le Worker ne reçoit plus d'erreur pour le cas compatible démontré.
+
+### `pre.014-fix.002` — correction du canari PostgreSQL et résultat live prolongé
+
+Le gate opérateur de `pre.014-fix.001` confirme les audits statiques et `cargo check --workspace`, puis échoue pendant Clippy/tests sur le nouveau test PostgreSQL : `RawTimestamp::unix_millis()` renvoie `u64` alors que la ligne de test `RawTransactionRow::block_time_unix_millis` attend `Option<i64>`. Le fixture concerné utilise `block_time=None`, mais Rust doit tout de même typer la closure. `fix.002` remplace la projection de test par une conversion sûre `i64::try_from(...).ok()` ; aucun comportement de production n'est modifié.
+
+Le même run live apporte deux preuves distinctes. D'abord, le comportement `fix.001` est confirmé sur plusieurs transactions Mainnet : le backend PostgreSQL accepte les `logMessages` entrants explicitement tronqués comme observations compatibles sans remplacer le canonique complet et sans produire de `content_conflict`. Les couples observés incluent `159/144`, `176/119`, `136/133` et `154/141` lignes `stored/incoming`.
+
+Ensuite, un `grpc_backpressure_overflow` réapparaît sur Yellowstone Mainnet lors d'un run prolongé. Le WARN Transport survient à `22:09:54`, plus de deux minutes avant le Stop opérateur à `22:12:03`; il ne s'agit donc pas d'une race de shutdown. Le correctif `pre.013` a supprimé le couplage strictement séquentiel, mais sa file privée de `256` slots pending et ses `8` hydratations concurrentes ne suffisent pas lorsque le débit aval moyen reste durablement inférieur au débit gRPC. Conformément à `VER-LIFECYCLE-010`, cette anomalie du couloir acquisition Yellowstone ne sera pas mélangée à `pre.014-fix.002` : elle ouvre la prochaine prerelease dédiée, avant de rejouer le gate technique/live final.
+
+Non-claims de `fix.002` : aucun changement de Transport, Worker runtime, Store production, politique de conflit ou capacité de queue. Le seul changement Rust est la correction de typage du test PostgreSQL.
+