v0.3.12-pre.008

This commit is contained in:
2026-09-09 20:42:32 +02:00
parent 90c266d68a
commit 2aa64cf0a4
17 changed files with 879 additions and 47 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/029-V0_3_12_YELLOWSTONE_HYDRATION_CONTINUITY.md -->
<!-- version: 15 -->
<!-- version: 16 -->
# Validation v0.3.12 — Yellowstone + hydration HTTP + continuité de run du Worker RawTransaction
@@ -1492,3 +1492,163 @@ Le correctif `pre.007-fix.002` ne modifie donc pas le runtime. Il rend le canari
Aucune définition pending/settled, compaction, projection snapshot, source Yellowstone, hydration, admission, persistence, API publique, reconnect ou replay n'est modifiée.
Les validations Cargo de ce correctif restent à rejouer par l'opérateur.
## 65. Gate opérateur `pre.007-fix.002`
Le gate opérateur communiqué pour `0.3.12-pre.7.fix.2` est entièrement vert :
```text
General Rust rule audit : clean
Rust export completeness audit : 0 candidate(s)
KSP workspace Rust rule audit : clean
Markdown table audit : clean (340 tables, 814 fichiers)
cargo check --workspace : PASS
cargo clippy --workspace --all-targets --all-features -- -D warnings : PASS
cargo test -p ksp-worker-raw-transaction-ingest-lib : 61 unit PASS / 0 FAIL
dependency_boundary : 8 PASS / 0 FAIL
hardening : 14 PASS / 0 FAIL
public_api : 9 PASS / 0 FAIL
release_completeness : 3 PASS / 0 FAIL
doc-tests : 0 FAIL
```
`pre.007-fix.002` devient donc la base autoritaire de `pre.008`.
## 66. Observation reconnect/replay Transport `pre.008`
Le moteur Yellowstone Transport possédait déjà la politique de reconnect bornée, la sélection `from_slot`, `SubscribeReplayInfo` et les compteurs conservateurs. `pre.008` n'en duplique aucune partie dans le Worker.
Transport ajoute uniquement une façade latest-value clonable et sûre :
```text
YellowstoneGrpcSubscribeSnapshotSource
current() -> YellowstoneGrpcSubscribeSnapshot
wait_for_change() -> Option<YellowstoneGrpcSubscribeSnapshot>
SolanaYellowstoneGrpcSubscribeSession::snapshot_source()
```
Le `tokio::sync::watch::Receiver` reste privé à Transport. Cloner la source de snapshot ne clone ni le stream gRPC, ni le request state, ni l'actor de reconnect.
Un canari Transport vérifie qu'un replay attempt peut être observé pendant `Reconnecting` alors que `reconnect_count == 0`. Le Worker peut donc distinguer :
```text
reconnect intent/progress
replay-bearing attempt
successful reconnect
proven retention gap
```
sans inférer ces états à partir des updates métier.
## 67. Projection source-neutral Worker `pre.008`
Le Worker étend la même projection latest-value privée déjà utilisée par la processing frontier. Aucun second channel Worker n'est ajouté.
Le snapshot concret expose :
```text
source_state : Option<RawTransactionIngestSourceState>
source_reconnect_total : u64
source_replay_attempt_total : u64
source_continuity_gap_total : u64
```
`RawTransactionIngestSourceState` est strictement source-neutral :
```text
Active
Reconnecting
Closing
Closed
Failed
```
La projection ne contient ni signature, filtre, provider, endpoint, payload RAW, `from_slot`, `first_available` ou `ReplayInfo`.
Pendant `Reconnecting`, les hydrations HTTP déjà en vol et la processing frontier restent intactes. `WorkerActivity` est `Active` pendant `Reconnecting` ou `Closing`, même si les queues aval sont momentanément vides.
## 68. Politique conservative de gap `pre.008`
Le Worker ne fault pas parce qu'un reconnect commence, qu'un replay est tenté ou qu'un `from_slot` est accepté.
La seule preuve de discontinuité utilisée est une hausse de :
```text
YellowstoneGrpcSubscribeSnapshot::continuity_gap_count()
```
Ce compteur est incrémenté exclusivement par Transport lorsqu'un `SubscribeReplayInfo.first_available` est strictement supérieur à la slot demandée. Cela prouve que la couverture de replay demandée n'est plus entièrement retenue ; cela ne prouve pas qu'un update correspondant au filtre a réellement existé ou a été perdu.
Quand ce compteur augmente :
```text
projection gap publiée avec les compteurs courants
source task -> erreur interne source.continuity_gap_proven
supervisor -> ERROR_CODE_RAW_TRANSACTION_INGEST_SOURCE_FAILED
Worker -> fault/stop
```
Aucun repair, backfill implicite, `getBlock`, source secondaire ou checkpoint durable n'est déclenché.
Les compteurs reconnect/replay/gap observés par le Worker doivent rester monotones ; une régression impossible de snapshot est classée `source.continuity_counter_regression`.
## 69. Ownership replay et non-claims `pre.008`
Le Worker ne contient aucun appel à :
```text
subscribe_replay_info(...)
set_from_slot(...)
YellowstoneReplayInfo
last_requested_from_slot()
```
Ces primitives restent entièrement dans `ksp-onchain-transport-lib`. En particulier, le Worker ne calcule, ne clamp et ne persiste jamais de `from_slot`.
`pre.008` ne prétend pas :
```text
qu'un replay accepté est lossless
qu'un replay successful prouve la continuité complète
faire un repair historique automatique
faire un failover multi-provider
maintenir un checkpoint inter-process
dédupliquer exactement-once
transformer processing_frontier en preuve de durabilité ou de complétude blockchain
```
## 70. Canaris et gate requis pour `pre.008`
Les canaris déterministes ajoutés couvrent :
```text
watcher Transport latest-value clonable sans fuite Tokio publique
replay_attempt_count > 0 possible avant reconnect_count > 0
mapping exact des cinq états source-neutral
reconnect/replay/gap counters projetés dans le snapshot Worker
processing frontier préservée pendant Reconnecting
gap prouvé -> erreur source.continuity_gap_proven
régression de compteur -> source.continuity_counter_regression
aucun ownership Worker de ReplayInfo/from_slot/repair
frontier pre.007 toujours processing-only
inventaire public Worker mis à jour exactement
redaction de la projection reconnect/replay
```
Gate opérateur requis :
```bash
cargo fmt --all
python3 scripts/audit_rust_workspace_rules.py
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test -p ksp-onchain-transport-lib
cargo test -p ksp-worker-raw-transaction-ingest-lib
cargo tree -p ksp-worker-raw-transaction-ingest-lib --edges normal
cargo tree -p ksp-worker-raw-transaction-ingest-lib -e features
cargo tree --duplicates
```
Dans l'environnement d'assemblage, `cargo`, `rustc` et `rustfmt` ne sont pas installés ; aucun gate Cargo local n'est revendiqué.