Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.3.15-pre.015

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-18 21:06:58 +02:00
parent b266019ea8
commit 582a286baa
9 changed files with 323 additions and 54 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md -->
<!-- version: 23 -->
<!-- version: 24 -->
# Plan v0.3.15 — Raw Transaction Ingest Desk
@@ -342,7 +342,7 @@ La documentation Helius actuelle indique que `blockSubscribe` n'est pas support
| Store open / network / partage `Arc<Store>` | aucun gap | Store + app | `ksp-store-lib` suffit |
| Lifecycle / stop / snapshots Worker | aucun gap | Worker + app | handles publics existants |
| Backfill / historical repair | hors scope | Job Backfill | aucune orchestration automatique |
| Taille release | pas de split de release | plan | forecast étendu jusqu’à `pre.017` |
| Taille release | pas de split de release | plan | forecast étendu jusqu’à `pre.018` |
La release n'est pas rescindée. Le gap WS est petit, clairement propriétaire et testable. En revanche, le forecast doit être étendu pour ne pas fusionner Transport, Config, Worker et scaffold UI dans une même tranche.
@@ -668,7 +668,7 @@ Le build Tauri final reste un gate tardif et ne remplace pas les tests runtime.
## 20. Forecast recalibré — prereleases souples
Le forecast initial `pre.002 -> pre.013` est désormais étendu jusqu'à `pre.017`. La cause n'est pas une inflation UI : c'est la découverte d'un contrat WS capability manquant qui doit être fermé proprement dans Transport, Config puis Worker avant consommation par la Desk.
Le forecast initial `pre.002 -> pre.013` est désormais étendu jusqu'à `pre.018`. La cause n'est pas une inflation UI : c'est la découverte d'un contrat WS capability manquant qui doit être fermé proprement dans Transport, Config puis Worker avant consommation par la Desk.
Le forecast reste volontairement souple. Chaque prerelease possède une sous-section directement éditable ; lorsqu'un correctif est nécessaire, il est ajouté sous la prerelease concernée avec un titre `#### pre.NNN-fix.MMM`. Les responsabilités de clôture `gate technique/live -> réconciliation documentaire -> préparation de publication` restent séparées.
@@ -849,15 +849,15 @@ Budget cible : une tranche hardening.
### `pre.013` — Yellowstone Block hydration backpressure
**État : implémenté, gate opérateur requis.** Le live de `pre.012-fix.004` a reproduit deux `grpc_backpressure_overflow` Mainnet environ 79 s puis 81 s après démarrage Yellowstone. Les WARN Transport précèdent les Stop opérateur de plusieurs secondes : la cause est donc le couplage historique `Block update -> getBlock HTTP -> admission de toutes les transactions -> lecture de l'update suivante`, et non la sémantique Stop. Conformément à `VER-LIFECYCLE-010`, ce défaut du couloir acquisition antérieur ouvre une nouvelle prerelease dédiée au lieu d'un `pre.012-fix.005`.
**État : implémenté ; amélioration confirmée, saturation prolongée rouverte en `pre.015`.** Le live de `pre.012-fix.004` a reproduit deux `grpc_backpressure_overflow` Mainnet environ 79 s puis 81 s après démarrage Yellowstone. Les WARN Transport précèdent les Stop opérateur de plusieurs secondes : la cause initiale est donc le couplage historique `Block update -> getBlock HTTP -> admission de toutes les transactions -> lecture de l'update suivante`, et non la sémantique Stop. Conformément à `VER-LIFECYCLE-010`, ce défaut du couloir acquisition antérieur a ouvert une prerelease dédiée au lieu d'un `pre.012-fix.005`.
Le mode Yellowstone Block reçoit désormais une partition déterministe des budgets d'hydration déjà possédés par le Worker. Les slots gRPC sont placés dans un coordinateur privé borné ; plusieurs `getBlock` peuvent progresser concurremment jusqu'au quota `in-flight`, et chaque tâche porte aussi l'admission complète de son bloc avant settlement du slot. La boucle source continue de consommer `session.next_update()` tant qu'une capacité pending existe. Aucun changement de capacité Transport, aucune queue non bornée et aucun drop silencieux ne masquent une surcharge durable.
Le mode Yellowstone Block reçoit désormais une partition déterministe des budgets d'hydration déjà possédés par le Worker. Les slots gRPC sont placés dans un coordinateur privé borné ; plusieurs `getBlock` peuvent progresser concurremment jusqu'au quota `in-flight`, et chaque tâche porte aussi l'admission complète de son bloc avant settlement du slot. La boucle source continue de consommer `session.next_update()` tant qu'une capacité pending existe. Cette correction supprime le couplage strictement séquentiel, mais un live plus long a ensuite prouvé qu'une saturation durable des bornes Worker puis Transport restait possible ; cette seconde responsabilité est isolée en `pre.015`.
Budget cible : une tranche corrective acquisition/throughput, suivie d'un live Mainnet prolongé.
Budget cible : une tranche corrective acquisition/throughput, suivie du complément Transport de `pre.015`.
### `pre.014` — convergence inter-provider + completeness/security cross-layer
**État : implémenté, gate/live opérateur requis.** Le gate de `pre.013` compile et teste proprement le workspace et le live ne reproduit plus `grpc_backpressure_overflow`. Un unique `content_conflict` Mainnet réapparaît toutefois entre HTTP Block Polling (`solana_mainnet_public`) et Yellowstone hydraté par HTTP (`publicnode_solana_mainnet_rpc`), tous deux en `confirmed`. Le diagnostic `pre.012-fix.004` prouve que `slot`, `block_time`, transaction wire, version et `transactionIndex` sont identiques ; seule la valeur `meta.logMessages` diverge.
**État : implémenté et gate opérateur PASS après `pre.014-fix.003`.** Le premier live après `pre.013` n'a pas reproduit immédiatement `grpc_backpressure_overflow`, mais un unique `content_conflict` Mainnet est apparu entre HTTP Block Polling (`solana_mainnet_public`) et Yellowstone hydraté par HTTP (`publicnode_solana_mainnet_rpc`), tous deux en `confirmed`. Le diagnostic `pre.012-fix.004` a prouvé que `slot`, `block_time`, transaction wire, version et `transactionIndex` étaient identiques ; seule la valeur `meta.logMessages` divergeait.
La tranche ne normalise ni n'ignore `logMessages`. Elle ajoute un diagnostic de convergence sûr permettant de distinguer un fork `confirmed` d'une divergence de représentation/provider : chaque `getBlock` réussi des deux routes journalise le slot et un fingerprint SHA-256 irréversible de l'identité de bloc (`blockhash`, `previousBlockhash`, `parentSlot`, `blockHeight`) sans exposer les blockhash. En cas de conflit RAW, Store journalise désormais les slots exacts et une forme bornée de la divergence `logMessages` : état absent/null/array, cardinalités, premier index divergent, type statique de la première ligne divergente, longueur, relation de préfixe et présence d'un marqueur de troncature. Aucun texte de log distant n'est copié.
@@ -867,19 +867,29 @@ Les canaris de clôture continuent de vérifier dependency firewalls, API publiq
Budget cible : une tranche de convergence/completeness cross-layer, sans modification de la politique fail-closed.
### `pre.015` — gate technique/live final
### `pre.015` — Yellowstone sustained gRPC backpressure
**État : en cours.** Le live prolongé de `pre.014-fix.001` a reproduit `Yellowstone subscribe update queue overflowed` à `22:09:54`, alors que le Stop opérateur n'est demandé qu'à `22:12:03`. `pre.013` a donc amélioré le débit sans fermer le défaut durable : lorsque les `256` slots pending Worker sont pleins, le Worker suspend `next_update()` ; la queue Transport bornée de `256` updates finit ensuite par se remplir et son ancien `try_send` transforme cette pression locale en faute terminale `grpc_backpressure_overflow`.
La correction conserve toutes les bornes et n'augmente aucune queue. L'acteur Yellowstone Transport remplace uniquement l'envoi non bloquant de l'update décodée par un `send().await` sélectionné avec le signal de shutdown prioritaire. Une queue pleine suspend ainsi le polling du stream Tonic et propage la backpressure au flux gRPC/HTTP/2 ; lorsque le consumer libère une place, la livraison reprend. Aucun update n'est dropé et aucune allocation non bornée n'est introduite. `grpc_backpressure_overflow` reste un code public valide pour les queues de mutations de requête synchrones/fail-fast et les bornes de message ; seule la saturation de la queue d'updates reçues cesse d'être un terminal local.
Le gate live doit dépasser la durée de reproduction précédente : Yellowstone Mainnet seul puis Yellowstone + HTTP Block Polling doivent chacun rester actifs au moins 10 minutes, sans WARN `Yellowstone subscribe update queue overflowed`, sans `grpc_backpressure_overflow` et avec Stop ciblé terminant `Stopped`. Une vraie rupture distante reste traitée par le reconnect/replay borné existant.
Budget cible : une tranche corrective Transport/acquisition, sans croissance d'API publique.
### `pre.016` — gate technique/live final
Exécuter le workspace complet, Clippy strict, suites ciblées, graphes/duplicates, smokes réellement accessibles et build frontend/Tauri final. Aucun nouveau scope métier.
Budget cible : une tranche technique.
### `pre.016` — réconciliation documentaire finale
### `pre.017` — réconciliation documentaire finale
Réconcilier plan, validation, README/USAGE et documents durables réellement affectés. Ne pas modifier CHANGELOG, ROADMAP ni le prompt suivant.
Budget cible : une tranche documentaire.
### `pre.017` — préparation de publication
### `pre.018` — préparation de publication
Préparer le prompt suivant, CHANGELOG, ROADMAP et la mécanique minimale de version/delta. Aucun rattrapage fonctionnel ou documentaire durable.
@@ -922,7 +932,7 @@ aucun gap Store / HTTP / lifecycle Worker essentiel
capability WS fine = gap lower-layer réel à fermer avant UI
Helius standard WS != Helius transactionSubscribe
aucune route rendue disponible à partir d'un exemple Config ou du provider name
forecast recalibré jusqu'à pre.017
forecast recalibré jusqu'à pre.018
```
`pre.002` doit donc commencer par le contrat Transport de capabilities WS, et non par le scaffold Tauri.

61
docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md -->
<!-- version: 31 -->
<!-- version: 32 -->
# Validation v0.3.15 — Raw Transaction Ingest Desk
@@ -276,7 +276,7 @@ Aucune de ces informations Web n'est convertie directement en route sélectionna
| Store open / network / partage `Arc<Store>` | aucun gap | Store + app | `ksp-store-lib` suffit |
| Lifecycle / stop / snapshots Worker | aucun gap | Worker + app | handles publics existants |
| Backfill / historical repair | hors scope | Job Backfill | aucune orchestration automatique |
| Taille release | pas de split de release | plan | forecast étendu jusqu’à `pre.016` |
| Taille release | pas de split de release | plan | forecast étendu jusqu’à `pre.018` |
Résultat : `0.3.15` reste une release cohérente. Aucun split vers `0.3.16` n'est nécessaire avant implémentation, mais le forecast interne est élargi.
@@ -465,19 +465,23 @@ Races, shutdown app, sécurité IPC, hardening hostile/stale inventory.
Découplage borné réception gRPC / `getBlock` / admission pour la route Yellowstone Block, conformément à `VER-LIFECYCLE-010`.
### `pre.014` — completeness
### `pre.014` — convergence inter-provider + completeness
Cross-layer completeness + canaris système sans expansion de frontières.
Diagnostic puis compatibilité étroite des `logMessages` explicitement tronqués, avec canaris cross-layer et sans expansion de frontières publiques.
### `pre.015` — gate technique/live
### `pre.015` — Yellowstone sustained gRPC backpressure
La saturation locale de la queue d'updates Yellowstone doit appliquer une backpressure asynchrone bornée au stream gRPC au lieu de produire un terminal `grpc_backpressure_overflow`.
### `pre.016` — gate technique/live
Gate technique/live accessible + frontend/Tauri + build final de validation technique.
### `pre.016` — réconciliation documentaire
### `pre.017` — réconciliation documentaire
Plan/validation/README/USAGE uniquement selon les surfaces réellement affectées.
### `pre.017` — préparation publication
### `pre.018` — préparation publication
Prompt suivant + CHANGELOG + ROADMAP + mécanique minimale de publication.
@@ -1005,3 +1009,46 @@ Le gate opérateur de `pre.014-fix.002` confirme la correction de typage : les a
Non-claim : ce fix ne traite pas le `grpc_backpressure_overflow` Yellowstone prolongé déjà identifié ; ce défaut ouvre toujours la prochaine prerelease acquisition dédiée après fermeture du gate `pre.014`.
### `pre.015` — backpressure gRPC Yellowstone soutenue sans overflow local
Le gate opérateur de `pre.014-fix.003` ferme la prerelease `pre.014` : audits Rust/Markdown propres, `cargo check --workspace`, Clippy strict, `ksp-store-postgres-lib` (`75/75` unitaires et `16/16` hardening completeness), Worker (`161/161` unitaires et suites externes), Raw Transaction Ingest Desk et `cargo test --workspace --all-targets --all-features` passent. Le canari de non-réécriture canonique resserré par `fix.003` est donc validé.
Le défaut acquisition restant provient du live prolongé précédent et ne relève pas du Store. Le WARN `Yellowstone subscribe update queue overflowed` apparaît à `22:09:54`, tandis que le Stop Yellowstone n'est demandé qu'à `22:12:03`. `content_conflict_total=0` au terminal. La chaîne de saturation est désormais établie :
```text
Worker Yellowstone Block pending plein (borne 256)
-> Worker suspend session.next_update()
-> queue Transport update bornée (borne 256) se remplit
-> ancien update_tx.try_send(...) retourne Full
-> grpc_backpressure_overflow local
-> source_failed / Faulted
```
`pre.015` ne change ni les valeurs `256/8`, ni le Store, ni le payload RAW, ni le reconnect budget. L'acteur Subscribe Yellowstone conserve sa queue d'updates bornée mais attend désormais asynchronement sa capacité avec `update_tx.send(...).await`. Le même `tokio::select!` donne priorité au shutdown afin qu'un Stop reste préemptif même lorsque le consumer ne draine plus la queue. Pendant l'attente, le stream Tonic n'est plus pollé ; la pression est donc propagée au transport gRPC/HTTP/2 au lieu d'être transformée en erreur locale ou en drop.
Canaris requis :
```text
yellowstone_slow_receiver_applies_bounded_backpressure_without_terminal_overflow
release_v0_3_15_pre_015_yellowstone_update_delivery_backpressures_without_local_overflow
```
Non-claims : aucune garantie lossless/exactly-once, aucune queue non bornée, aucun agrandissement de capacité, aucune modification WebSocket, aucun changement de la queue de mutations Yellowstone qui reste synchrone/fail-fast, aucune suppression du code public `grpc_backpressure_overflow`, aucune nouvelle API publique.
Gate opérateur attendu :
```text
cargo fmt --all
cargo fmt --all -- --check
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/0.3.15
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test -p ksp-onchain-transport-lib --all-targets --all-features
cargo test -p ksp-worker-raw-transaction-ingest-lib --all-targets --all-features
cargo test -p ksp-app-raw-transaction-ingest-desk --all-targets --all-features
cargo test --workspace --all-targets --all-features
```
Gate live Mainnet : Yellowstone seul pendant au moins 10 minutes, puis Yellowstone + HTTP Block Polling pendant au moins 10 minutes. Dans les deux cas, aucune occurrence de `Yellowstone subscribe update queue overflowed` ou `grpc_backpressure_overflow` n'est admise ; la route Yellowstone doit rester active/saine jusqu'au Stop ciblé, puis terminer `Stopped`. Une interruption réseau distante réellement observée doit rester classée par les codes Transport/reconnect existants et ne doit pas être confondue avec ce gate de saturation locale.