68 KiB
Validation v0.3.15 — Raw Transaction Ingest Desk
1. Rôle
Ce document enregistre les preuves et non-claims de 0.3.15. En pre.001, aucune crate Desk, aucun Start/Stop Worker et aucune extension lower-layer ne sont encore implémentés : la tranche est exclusivement le gate de lecture, audit, brainstorming, external re-audit, sizing et planification imposé par prompts/034-V0_3_15_START_PROMPT.md.
2. Archive stable contrôlée
archive : khadhroony-solana-project-v0.3.14.zip
SHA-256 : 897bd30b0d06c00abc120a7459250b78c11629e84825ac29adbe151d60a668ed
bytes : 8591925
entries : 2046
files : 1851
absolute entries : 0
parent traversal entries : 0
duplicate entries : 0
symlink entries : 0
workspace members : 21
crate manifests : 21
workspace.package.version : 0.3.14
edition : 2024
stable delta : deltas/0.3.14/rel.001.md
Artefacts interdits recherchés :
Cargo.lock : absent
package-lock.json : absent
pnpm-lock.yaml : absent
yarn.lock : absent
rust-toolchain.toml : absent
.env : absent
target/ : absent
node_modules/ : absent
dist/ : absent
.git/ : absent
Résultat archive : PASS.
L'absence de .git empêche de comparer l'objet du tag v0.3.14; aucune équivalence cryptographique au tag n'est revendiquée.
3. Preuve opérateur stable fournie
Le journal opérateur joint à la demande contient notamment l'exécution stable 0.3.14 de :
cargo clean
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
cargo check --workspace
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test -p ksp-worker-raw-transaction-ingest-lib --all-targets --all-features
cargo test --workspace --all-targets --all-features
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
Les sorties fournies montrent notamment :
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
KSP workspace Rust rule audit: clean
Markdown table audit: clean (340 table(s), 886 file(s))
Worker unit tests: 152 passed / 0 failed
Worker cross-layer completeness: 12 passed / 0 failed
Worker dependency boundary: 21 passed / 0 failed
Worker hardening: 38 passed / 0 failed
Worker public API: 22 passed / 0 failed
Worker release completeness: 15 passed / 0 failed
Le journal continue avec le gate workspace stable et ses tests. Cette preuve qualifie l'entrée 0.3.14; elle n'est pas réutilisée comme prétendue exécution post-bump 0.3.15-pre.1.
4. Audits locaux de la base avant modification
Exécuté localement :
python3 scripts/audit_rust_workspace_rules.py
Résultat :
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
KSP workspace Rust rule audit: clean
Exécuté localement :
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas
Résultat :
Markdown table audit: clean (340 table(s), 886 file(s))
cargo/rustfmt ne sont pas présents dans l'environnement d'assemblage courant. Aucune commande Cargo locale n'est déclarée PASS.
5. Audit des règles
Documents relus :
RULES.md
ROADMAP.md
CHANGELOG.md
docs/000-README.md
docs/rules/RULES_GENERAL.md
docs/rules/RULES_KSP.md
docs/rules/RULES_RUST.md
docs/rules/RULES_DEPENDENCIES.md
docs/rules/RULES_DOCUMENTATION.md
docs/rules/FILE_CONTRACTS.md
docs/rules/VERSION_WORKFLOW.md
docs/rules/PROMPT_STRUCTURE.md
Scan des définitions normatives :
489 définitions
489 IDs uniques
0 doublon
Les deltas publiés antérieurs ne sont pas réécrits. Le gate pre.001 modifie uniquement Cargo.toml et ajoute les trois livrables exigés.
6. Handoff stable et Worker audités
Les documents 0.3.14, README/USAGE Worker et les sources/tests Worker ont été audités.
API publique pertinente confirmée :
RawTransactionIngestRuntimeResources
RawTransactionIngestYellowstoneSource
RawTransactionIngestStandardLogsSource
RawTransactionIngestStandardBlockSource
RawTransactionIngestHeliusTransactionSource
RawTransactionIngestHttpBlockPollingSource
RawTransactionIngestWorker::start_with_runtime_resources
RawTransactionIngestHandle
RawTransactionIngestSnapshotSource
Frontières confirmées :
Worker -X-> Config
Worker -X-> Job Backfill
Worker -X-> ksp-store-postgres-lib
Worker -> ksp-store-lib
Worker -> ksp-onchain-transport-lib
Plusieurs Workers peuvent recevoir le même Arc<Store> ; leurs lifecycle/gaps/TargetCoverage restent indépendants.
7. Requirements exacts des cinq familles Worker
| Route V1 | Network | Required capability | Optional capability | Config evidence | Worker resource | Composable aujourd’hui ? | Missing contract | Live-testable ? |
|---|---|---|---|---|---|---|---|---|
yellowstone-hydrated |
réseau du profil | Yellowstone gRPC Block Subscribe + HTTP getBlock même réseau |
reconciliation HTTP bloc multi-provider | gRPC + HTTP role | RawTransactionIngestYellowstoneSource |
oui sur profil complet et secrets résolus | aucun contrat essentiel | provider-gated selon profil |
standard-logs-hydrated |
réseau du profil | WS Solana standard logsSubscribe + HTTP getTransaction |
scan HTTP repair si rôle compatible | WS + HTTP role | RawTransactionIngestStandardLogsSource |
non prouvable strictement avant capability WS explicite | Transport + Config + enforcement Worker minimaux | oui, notamment Devnet keyless après extension |
standard-block-direct |
réseau du profil | WS Solana standard blockSubscribe explicitement déclaré |
aucune hydration obligatoire | WS capability Block | RawTransactionIngestStandardBlockSource |
non prouvable aujourd’hui | Transport + Config + enforcement Worker minimaux | seulement endpoint prouvé compatible |
helius-transaction-hydrated |
réseau du profil | WS Helius transactionSubscribe + HTTP getTransaction |
scan HTTP repair si rôle compatible | Helius WS + HTTP role | RawTransactionIngestHeliusTransactionSource |
non dans les profils committed actuels | Config data/composite + capability WS explicite | provider-gated Helius |
http-block-polling |
réseau du profil | HTTP getSlot + getBlocksWithLimit + getBlock |
getTransaction pour known-reference hydration |
HTTP role | RawTransactionIngestHttpBlockPollingSource |
oui lorsque le rôle résolu annonce les trois méthodes | aucun contrat essentiel | oui sur endpoint public compatible |
Qualification importante : Composable aujourd'hui ? signifie « prouvable à partir de la Config stable telle qu'elle est structurée », pas « le provider distant répond actuellement ».
8. Audit Config
ResolvedTransportConfig fournit des settings typed HTTP/WS/gRPC et ResolvedStoreConfig fournit les settings Store sans exiger une lecture JSON frontend.
HTTP : rôles et request_kinds sont déjà projetables côté Rust.
WS : le protocol kind est projetable, mais WsEndpointSettings ne porte pas de liste de WsSubscriptionKind. C'est le gap déterminant de pre.001.
Profils Transport sources audités (ils ne constituent pas les profils applicatifs du Desk) :
| Profil/config | Réseau | Surfaces | Secret requis | Committed ? | Observation |
|---|---|---|---|---|---|
devnet_public |
devnet | HTTP + WS Solana standard | non | oui | pas de capability WS fine aujourd’hui |
orbitflare_devnet |
devnet | HTTP + WS standard + Yellowstone gRPC | token gRPC secret | conditionnel | profil complet seulement si secret résolu |
mainnet_public |
mainnet | HTTP + WS Solana standard | non | oui | pas de capability WS fine aujourd’hui |
mainnet_backfill_pool |
mainnet | plusieurs HTTP + WS standard | selon endpoint/config | oui si profil résolu | priorités/rôles restent Transport-owned |
publicnode_mainnet |
mainnet | HTTP + WS standard + Yellowstone gRPC | x-token secret | conditionnel | source Yellowstone same-network |
testnet_public |
testnet | HTTP + WS Solana standard | non | oui | socle keyless Testnet |
publicnode_testnet |
testnet | HTTP + WS standard + Yellowstone gRPC | x-token secret | conditionnel | source Yellowstone same-network |
helius_devnet |
devnet | HTTP public + WS Helius | API key secret | conditionnel | source Helius same-network |
helius_mainnet |
mainnet | HTTP public + WS Helius | API key secret | conditionnel | source Helius same-network |
Ces profils sont des sources Transport. Le composite applicatif Raw Ingest les agrège désormais sous devnet, mainnet et testnet; un provider n'est jamais une identité réseau.
9. Audit Store
Chemin validé :
ResolvedStoreConfig -> StoreSettings -> ksp-store-lib::Store::open
Aucun besoin de nouvelle API Store n'est identifié pour inventaire, Start/Stop ou partage du Store entre Workers du même réseau.
10. Audit gabarit Desk
Les cinq Desk KSP existantes ont été utilisées comme références de structure et non comme code à copier pendant pre.001.
Socle confirmé :
splash KSP commun
fonts/style KSP
backend Tauri Rust propriétaire des ressources
frontend sans accès direct réseau/Store/secrets
@fltsci/tauri-plugin-tracing
@fortawesome/fontawesome-free
@tauri-apps/api
bootstrap
resize-observer-polyfill
simplebar
Aucun upgrade npm opportuniste n'est retenu.
11. External re-audit pre.001
Sources primaires/courantes consultées pour qualifier les capabilities :
Solana JSON-RPC WebSocket blockSubscribe
Solana JSON-RPC WebSocket logsSubscribe
Yellowstone gRPC upstream Subscribe/proto/changelog
Helius WebSocket standard + transactionSubscribe + unsupported methods
PublicNode Solana RPC/WS/Yellowstone offre actuelle
OrbitFlare Yellowstone gRPC offre actuelle
Constats utilisés :
blockSubscribe est unstable et dépend de l'activation côté validator/provider
logsSubscribe est standard
Helius distingue les méthodes Solana standard de son extension transactionSubscribe
Helius indique blockSubscribe non supporté
Yellowstone expose les filtres Subscribe et le replay/from_slot lower-layer
Aucune de ces informations Web n'est convertie directement en route sélectionnable : Config locale reste l'autorité de composabilité.
12. Gap classification
| Sujet | Classification | Owner | Décision |
|---|---|---|---|
| Catalogue de cinq routes et IDs applicatifs | adaptation app seulement | Desk | catalogue borné, pas de nouvelle crate |
Projection HTTP request_kinds / rôles / réseau |
aucun gap | Config + Transport | déjà exploitable côté Rust |
| Projection gRPC Yellowstone / metadata sûre | aucun gap | Config + Transport | secrets restent Rust-only |
| Capability WS exacte par subscription | extension Transport minimale | Transport | ajouter une déclaration typed réutilisant WsSubscriptionKind |
| Mapping schema/config des capabilities WS | extension Config minimale | Config | Config reste propriétaire de la déclaration |
| Refus Worker si capability WS requise absente | extension Worker minimale | Worker | enforcement avant I/O, pas de logique provider dans Desk |
| Composite dédié Raw Ingest Desk | extension Config minimale | Config | profils app dédiés et cohérents Store/Transport |
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 |
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.
13. Décisions UX / architecture validées au gate
catalogue de routes V1 app-owned
cinq route IDs bornés
réseau dérivé d'un composite/profil app cohérent Store+Transport
changement de profil interdit pendant Workers actifs
inventaire Config sans I/O réseau
Start revalide toute la Config
multiple endpoints satisfaisant une route : sélection Transport selon rôles/priorités
1 Worker par route
fault d'une route n'arrête pas les autres
Store partagé seulement si réseau strictement identique
fermeture app : stop/join de tous les Workers détenus
frontend sans endpoints/secrets/handles/source keys/payloads bruts
États UI retenus :
| État UI | Sémantique | Action principale |
|---|---|---|
| Unavailable | requirements incomplets ou incohérents | non |
| Configured | requirements Config complètes, aucune preuve runtime | oui |
| Starting | revalidation + reconstruction + ouverture Store + start Worker | non |
| Running | Worker actif, snapshots reçus | Stop |
| Stopping | stop demandé, attente terminale bornée | non |
| Stopped | Worker terminal propre, handle retiré | Start après nouvelle revalidation |
| Faulted | échec Start/runtime avec code sûr | Start après correction/revalidation |
14. IPC et tracing planifiés
| DTO candidat | Sens | Contenu autorisé | Exclusions |
|---|---|---|---|
RawIngestDeskOptionsDto |
backend -> frontend | profils logiques sûrs, réseaux, commitments supportés, génération inventaire | URL, secret, Store URI |
RawIngestRouteDto |
backend -> frontend | route_id, family, label, network, state, selectable, reason code | endpoint name/URL/token/source key |
RawIngestRouteStartRequestDto |
frontend -> backend | profile_id, route_id, inventory_generation, commitment | endpoint/credential/client |
RawIngestRouteStopRequestDto |
frontend -> backend | route_id | Worker handle |
RawIngestRouteRuntimeDto |
backend -> frontend | route_id, lifecycle/health/activity, compteurs source-neutral | payload brut, erreur provider arbitraire |
CommandErrorDto |
backend -> frontend | code stable + contexte whiteliste | texte remote arbitraire |
FrontendLogPayloadDto |
frontend -> backend | target/level/action IDs bornés | valeurs config/route sensibles |
| Interaction | Trace autorisée | Interdit |
|---|---|---|
| Navigation/tab | control_id + action | aucun profil, endpoint ou secret |
| Sélection profil/réseau | action + résultat code + counts | pas de valeur de secret ni URL |
| Sélection route | route family/route_id sûr + booléen | pas de source key |
| Start/Stop | route_id sûr + lifecycle outcome code | pas de payload Worker |
| Refresh/resync snapshots | action + sequence/count | pas de transactions |
| IPC success/failure | command id + stable code + durée éventuelle | pas d’erreur remote brute |
Ces tables décrivent le contrat de sécurité à implémenter ; elles ne revendiquent aucune commande Tauri existante en pre.001.
15. Sizing / forecast souple
Le forecast durable est porté par la section 20 du plan 036 sous forme hiérarchique éditable, et non par un tableau. La validation conserve ici la même séquence afin que le statut de chaque tranche puisse être complété sans réécrire la structure documentaire.
pre.001 — cadrage
Statut : réalisé. Audit, route model, external re-audit, sizing et plan/validation, sans code fonctionnel Desk.
pre.001-fix.001 — forme du forecast
Statut : réalisé ; documentaire uniquement. Le tableau de forecast initial est remplacé par la convention KSP ### pre.NNN / #### pre.NNN-fix.MMM. Aucun contenu fonctionnel du sizing n'est changé.
pre.002 — Transport WS capability
Statut : réalisé après pre.002-fix.001. Capability WS typed par subscription + tests, sans app. Le gate opérateur du fix passe cargo check, Clippy -D warnings et la suite Transport complète.
pre.003 — Config capability/composite
Statut : réalisé et gate opérateur PASS. Schema/mapping capabilities WS + composite/profils Raw Ingest Desk. Les profils standard committed déclarent la surface stable sans Block, les profils Helius déclarent explicitement HeliusTransaction sans Block/Vote, et les profils du composite Raw Ingest Desk couplent Transport+Store sur le même réseau. Le gate opérateur passe cargo check, Clippy -D warnings, cargo test -p ksp-config-lib --all-targets --all-features (130 tests unitaires PASS) et cargo test --workspace --all-targets --all-features.
pre.004 — Worker enforcement
Statut : réalisé et gate opérateur PASS. Les trois constructeurs de routes WS (Standard Logs, Standard Block, Helius Transaction) exigent la capability Transport exacte via supports_subscription(...) et refusent l'état undeclared/capability absente avant toute I/O. Le protocole reste validé avant la capability afin de conserver des diagnostics stables. Yellowstone et HTTP Block Polling ne sont pas concernés. Des canaris unitaires prouvent le refus undeclared/mauvaise capability et l'acceptation de la capability exacte ; les canaris hardening/release-completeness prouvent l'ordre avant connect, l'absence de logique provider et l'absence de croissance de surface publique. Le gate opérateur passe les audits, cargo check, Clippy strict, 153/153 tests unitaires Worker, les suites Worker d'intégration et le workspace all-targets/all-features complet.
pre.005 — scaffold Desk
Statut : réalisé et gate opérateur PASS après deux fixes. ksp-app-raw-transaction-ingest-desk existe comme crate Tauri mixte lib/bin, ports 1440/1441, splash/assets/fonts communs, Config/Logging et tracing frontend. pre.005-fix.001 retire un import Rust inutilisé détecté par Clippy. pre.005-fix.002 restaure le template clair commun des Desk KSP, corrige le débordement de #routeFoundation et le retour explicite du canari release-completeness. Le gate final passe audits, cargo check, Clippy strict, tests Desk, cargo test --workspace --all-targets --all-features et cargo tauri dev; le parcours visuel confirme le shell corrigé. Aucun script npm applicatif n'est lancé directement : Tauri déclenche ses hooks conformément à KSP-APP-034.
pre.006 — inventaire composable
Statut : gate opérateur de pre.006 en échec fonctionnel, puis corrections pre.006-fix.001, pre.006-fix.002 et pre.006-fix.003. Le premier inventaire classait encore les capabilities par profil Transport fournisseur : Yellowstone + HTTP hydration Mainnet n'était donc Configured que sous publicnode_mainnet. Le fix remplace cette projection par trois profils réseau (devnet, mainnet, testnet) qui agrègent les sources Transport same-network. PublicNode, Helius et OrbitFlare restent des sources de capabilities et ne deviennent jamais des identités réseau. Un secret optionnel absent n'invalide que la route dépendante. Le canari qui dépendait du Config utilisateur de la machine est remplacé par un moteur Config committé et un environnement injecté. Aucun I/O runtime n'est ajouté.
pre.006-fix.001 — correction classification réseau
Attendus : mainnet expose Yellowstone dès que la source PublicNode Mainnet est effectivement résolue, quelle que soit la source HTTP/WS standard retenue dans le même profil réseau ; mainnet reste utilisable pour Standard Logs et HTTP Block Polling lorsque les secrets Helius/PublicNode sont absents. Le même principe s'applique à Devnet et Testnet.
pre.006-fix.002 — Standard Block réellement composable
Le gate de pre.006-fix.001 révèle deux points : les canaris Desk ne compilent pas car ils appellent ConfigEnvironment::from_maps, helper pub(crate)/cfg(test) de ksp-config-lib, et standard-block-direct reste systématiquement indisponible parce qu'aucun endpoint standard committed ne déclare Block.
Le fix déclare explicitement Block sur les endpoints solana-public Standard WS committés de Devnet, Mainnet et Testnet, sans toucher Helius LaserStream. L'inventaire réseau-centrique projette donc standard-block-direct en Configured sur les trois réseaux. Cette classification reste une preuve Config de composabilité, pas une preuve live permanente : blockSubscribe reste unstable et validator/provider-gated, donc pre.007/Start devra reconstruire et revalider la ressource exacte avant exécution.
Les canaris Desk n'utilisent plus l'API crate-private de Config. Ils valident les routes standard à partir de ConfigEnvironment::load() et acceptent que les routes optionnelles Helius/Yellowstone soient soit Configured, soit missing_required_secret selon l'environnement opérateur.
pre.006-fix.003 — Helius Testnet non applicable
Le parcours visuel de pre.006-fix.002 montre toutes les routes composables en vert sauf helius-transaction-hydrated sur Testnet. Ce rouge était trompeur : le composite Testnet ne déclare aucune source transport.helius, et Helius Enhanced WebSocket transactionSubscribe n'est pas une capability Testnet configurée. Le fix ne falsifie donc pas la capability ; il retire cette route provider-specific de l'inventaire Testnet. Devnet/Mainnet continuent à la projeter et à la qualifier selon leur source Helius.
Le catalogue global reste exactement cinq IDs V1, mais l'inventaire d'un profil réseau contient uniquement les routes applicables à ses sources déclarées. Le canari frontend obsolète logical profile selected est également réaligné sur le tracing réseau-centrique logical network selected.
pre.007 — ressources Start
Statut : réalisé et gate opérateur PASS après pre.007-fix.001 et pre.007-fix.002. Le préflight backend validate_route_start est generation-bound et revalide la sélection contre un inventaire Config reconstruit avant toute ressource. La requête contient désormais profile_id + route_id + inventory_generation + commitment : profile_id est nécessaire depuis que les profils applicatifs sont réseau-centriques et qu'un même route ID existe sur plusieurs réseaux.
La preuve Start-time exige ensuite :
Store Config résolu et réseau identique
Transport de base résolu et same-network
source provider-specific résolue seulement pour Helius/Yellowstone
HTTP role unique satisfaisant l'ensemble des méthodes requises
WS/gRPC endpoint unique correspondant au protocole/capability/réseau
constructeur public Worker de la famille exacte accepté
Les cinq constructeurs source Worker sont effectivement réutilisés. HttpTransportPool::new et YellowstoneGrpcChannel::prepare restent sans requête réseau ; la source reconstruite est détruite immédiatement après validation. Sont encore interdits dans cette tranche : Store::open, connexion WS/gRPC active, RawTransactionIngestRuntimeResources, RawTransactionIngestWorker::start_with_runtime_resources, handle Worker, Start/Stop réel et état Running.
Attendus de sécurité : la réponse de préflight ne contient que profil logique, réseau, route, génération et commitment ; les erreurs lower-layer sont remappées derrière des codes/messages app bornés. Aucun endpoint, URL, credential, metadata secrète, URI Store, source key ou payload RAW ne traverse IPC.
pre.007-fix.001 corrige deux erreurs syntaxiques de l'assemblage initial (double visibilité pub(crate) et littéraux de canari mal échappés). pre.007-fix.002 rend le canari de reconstruction hermétique en l'adossant explicitement aux racines Config committées du workspace au lieu des racines par défaut de la machine. Le gate opérateur final de 0.3.15-pre.7.fix.2 passe audits Rust/Markdown, cargo check --workspace, Clippy workspace strict, les 34 tests unitaires Raw Ingest Desk, ses suites d'intégration et le workspace --all-targets --all-features; cargo tauri dev compile et lance ensuite l'application.
pre.008 — runtime mono-route
Implémenté dans l'assemblage de tranche : Start réutilise la revalidation pre.007, réserve un slot runtime unique, ouvre le Store exclusivement via ksp-store-lib, exige StoreHealthState::Ready, construit un WorkerId backend-owned puis appelle RawTransactionIngestWorker::start_with_runtime_resources. Le handle est installé avant l'accusé IPC.
Stop demande l'arrêt coopératif au handle et attend son état terminal. Un monitor backend indépendant attend également le terminal, récupère de manière bornée l'unique Arc<Store>, appelle explicitement Store::close() puis libère le slot. Les échecs avant installation du handle rollbackent le slot et ferment le Store déjà ouvert.
Surface IPC sûre ajoutée : start_route et stop_route, avec RawIngestRouteRuntimeDto limité à profile_id, network, route_id, inventory_generation, commitment et state. Aucune URL, credential, URI Store, source key, WorkerId, handle ou payload RAW n'est projeté.
Le frontend fournit un contrôle minimal Start/Stop mono-route et le choix confirmed/finalized. Il ne prétend pas encore fournir le monitoring continu : une terminaison spontanée est nettoyée backend-side mais sa projection temps réel demeure pre.010. Multi-route, Store partagé entre Workers et isolation inter-route demeurent pre.009.
pre.008-fix.004 — preuve live Mainnet et correction PublicNode
Le parcours live pre.008-fix.003 prouve que le channel Yellowstone PublicNode Mainnet s'ouvre et produit des transactions, mais que l'hydration était construite depuis le Transport de base mainnet_public. Les traces montraient donc le gRPC publicnode_solana_mainnet_yellowstone suivi de requêtes getTransaction via solana_mainnet_public, puis rate-limit/cooldown et overflow de queue.
Le fix corrige la composition : prepare_yellowstone prend désormais son role/pool HTTP dans le même ResolvedTransportConfig optionnel qui fournit le gRPC. Le profil publicnode_mainnet expose publicnode_solana_mainnet_rpc sur https://solana-rpc.publicnode.com, provider publicnode, sans recopier la limite locale 5 req/s du profil Solana-public. La concurrence locale reste bornée à 8 et le cooldown Transport sur 429 reste actif.
Non-claim : ce changement réduit une erreur de composition mais ne garantit pas qu'une hydration HTTP unitaire puisse suivre le firehose Mainnet. pre.009 choisit finalement Yellowstone Block -> getBlock multi-provider comme optimisation sûre ; la projection protobuf -> RAW directe reste non revendiquée.
pre.009 — optimisation Mainnet et runtime multi-route
La tranche matérialise un Worker indépendant par route, Stop ciblé, Store partagé uniquement sur identité réseau exacte et fermeture Store par la dernière route. Les faults restent route-local et aucune TargetCoverage/gap/frontier n'est partagée entre Workers.
La route Yellowstone bascule sur un filtre Block sans transactions embarquées puis reconcile le slot par getBlock Full/Base64. Le Worker distingue explicitement son ancien mode transaction-hydration du mode block-reconciliation ; ce dernier n'entre plus dans la registry d'hydration getTransaction. La récupération bloc est interruptible par Stop et retente de façon bornée lorsque le bloc n'est pas encore visible ou qu'un endpoint du pool échoue.
Le profil publicnode_mainnet contient deux endpoints HTTP de même rôle : PublicNode et Solana public repair. La validation doit prouver que Config conserve leurs limites séparées et que la route exige désormais getBlock, pas getTransaction. Le direct protobuf -> RAW n'est pas revendiqué.
pre.010 — monitoring
Implémenté dans l'assemblage de tranche. Le nouveau module route_monitoring projette les snapshots Worker existants vers un DTO latest-value source-neutral comprenant lifecycle, health, activity, admission/persistence, backpressure, hydration pending, processing frontier, continuité, source counts, reconnect/replay, gaps et repair. Le Worker expose uniquement les cinq getters de continuité qui manquaient à la façade publique de son snapshot ; aucun type ni comportement d'acquisition n'est ajouté.
Le Tauri backend démarre un monitor de snapshot indépendant pour chaque Worker lancé et émet ksp-raw-ingest-route-status vers la fenêtre principale. La commande get_route_monitoring permet une resynchronisation complète sans dépendre de la livraison de tous les événements intermédiaires. Le runtime conserve le dernier snapshot terminal sûr de chaque route jusqu'à un nouveau Start de la même identité ou au changement de session réseau.
Sécurité attendue : aucune URL, credential, provider physique, source key, WorkerId, handle, URI Store, signature ou payload RAW dans le DTO. Les u64 traversant IPC sont encodés en texte décimal ; les cardinalités bornées sont projetées en u32. Le monitor d'observabilité ne possède ni Store ni lifecycle et ne peut pas arrêter/redémarrer un Worker.
La consommation UI détaillée de ces snapshots et le tracing TypeScript associé restent pre.011.
pre.011 — frontend
Frontend fonctionnel complet + tracing TypeScript sûr.
pre.011-fix.001 — réactivité du monitoring frontend
Le gate statique de pre.011 est propre, mais l'essai Mainnet révèle une saturation de l'interface dès qu'une route Yellowstone productive est active : le Worker continue à hydrater des blocs, alors qu'aucune seconde action Start/Stop n'atteint le tracing frontend après le démarrage. La cause est applicative : monitor_route_status relayait chaque changement de séquence Worker et applyRouteMonitoring reconstruisait toute la grille de routes pour chaque snapshot. Sur un flux transactionnel soutenu, les boutons Start/Stop étaient donc remplacés continuellement dans le DOM et pouvaient perdre leur cible entre les événements pointeur/click.
Le fix conserve le contrat latest-value sans polling métier, mais borne le pont backend à une émission maximale toutes les 500 ms par route. Le snapshot terminal reste projeté ; entre deux émissions, la source watch conserve naturellement la dernière valeur. Côté TypeScript, les snapshots steady-state patchent uniquement les champs monitoring de la carte existante et le détail sélectionné. Une reconstruction complète des cartes n'est effectuée que lorsqu'aucune carte patchable n'existe ou lorsque le lifecycle change, ce qui maintient les boutons Start/Stop stables pendant l'activité normale.
Canari ajouté :
pre_011_fix_001_monitoring_bridge_is_bounded_and_steady_updates_preserve_route_controls
Ce correctif ne modifie ni Config, ni Transport, ni Store, ni Worker, ni Common RAW, ni les stratégies d'acquisition.
pre.012 — hardening
Races, shutdown app, sécurité IPC, hardening hostile/stale inventory.
pre.013 — Yellowstone Block hydration backpressure
Découplage borné réception gRPC / getBlock / admission pour la route Yellowstone Block, conformément à VER-LIFECYCLE-010.
pre.014 — completeness
Cross-layer completeness + canaris système sans expansion de frontières.
pre.015 — gate technique/live
Gate technique/live accessible + frontend/Tauri + build final de validation technique.
pre.016 — réconciliation documentaire
Plan/validation/README/USAGE uniquement selon les surfaces réellement affectées.
pre.017 — préparation publication
Prompt suivant + CHANGELOG + ROADMAP + mécanique minimale de publication.
rel.001 — stable
Publication mécanique uniquement, aucun rattrapage fonctionnel.
Le forecast initial du prompt n'est pas recopié : trois tranches lower-layer précèdent volontairement le scaffold UI.
16. Modifications pre.001
Ajouts :
docs/plans/036-V0_3_15_RAW_TRANSACTION_INGEST_DESK_PLAN.md
docs/validation/032-V0_3_15_RAW_TRANSACTION_INGEST_DESK.md
deltas/0.3.15/pre.001.md
Modification :
Cargo.toml
header 593 -> 594
workspace.package.version 0.3.14 -> 0.3.15-pre.1
Aucun fichier de production Rust, Config, frontend ou Tauri n'est modifié par le gate.
17. Validations post-modification
Exécuté localement après le bump et l’ajout des trois livrables :
python3 scripts/audit_rust_workspace_rules.py
Résultat :
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
KSP workspace Rust rule audit: clean
Exécuté localement :
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas
Résultat :
Markdown table audit: clean (354 table(s), 889 file(s))
Contrôles complémentaires :
rule definitions : 489
unique rule IDs : 489
duplicates : 0
stable -> worktree : 3 additions / 1 modification / 0 deletion
modified stable file : Cargo.toml seulement
Non exécuté localement :
cargo fmt --all -- --check : NON EXÉCUTÉ — cargo absent du sandbox
cargo check --workspace : NON EXÉCUTÉ — cargo absent du sandbox
cargo clippy --workspace --all-targets --all-features -- -D warnings : NON EXÉCUTÉ — cargo absent du sandbox
cargo test : NON EXÉCUTÉ — cargo absent du sandbox
Aucun de ces gates Cargo n’est déclaré PASS. Ils restent dans le gate opérateur après application du delta.
pre.009-fix.001 — shutdown Yellowstone et diagnostic de source
Le gate live pre.009 a confirmé le multi-route et le chemin Yellowstone Block -> getBlock, mais un Stop Yellowstone pouvait entrer en collision avec la deadline de fermeture gRPC de 5 s. Le défaut Worker de shutdown_drain_timeout passe à 10 s ; un timeout de session.close() après Stop déjà demandé est accepté comme fermeture coopérative uniquement pour onchain_transport.timeout, les autres fautes restant terminales. Les sources terminales tracent désormais uniquement leur famille logique et les codes d'erreur sûrs, afin de qualifier séparément le Faulted encore observé sur http-block-polling Mainnet sans le masquer.
pre.009-fix.002 — résultat du gate opérateur fix.001
Le gate opérateur fourni pour 0.3.15-pre.009-fix.001 confirme les points suivants :
cargo fmt --all / --check exécutés par l'opérateur
audit Rust workspace PASS
audit Markdown PASS (318 tables / 209 fichiers)
cargo check --workspace PASS
Clippy workspace strict -D warnings PASS
tests Raw Transaction Ingest Desk PASS
tests Worker FAIL : 156 PASS / 1 FAIL
tests workspace FAIL : canari logging en plus du test Worker
cargo tauri dev lancé et application opérationnelle
Les deux échecs statiques sont déterministes :
settings::pre_003_defaults_are_exact_and_preserve_typed_identity
settings.shutdown_drain_timeout() = 10 s
assertion restée à 5 s
workspace_logging::behavioral_crates_own_explicit_tracing_targets
target littéral ajouté dans runtime_resources.rs
règle workspace : cible possédée par src/constants.rs
Le live Mainnet ne valide pas encore le shutdown de fix.001 :
yellowstone-hydrated
acquisition getBlock productive
Stop demandé
~5 s plus tard : runtime_invalid, sans transport_domain/code
terminal : Faulted
http-block-polling
getSlot/getBlocks/getBlock productifs pendant ~48 s
Stop demandé
runtime_invalid quasi immédiat, sans transport_domain/code
terminal : Faulted
standard-logs-hydrated
fault avant Stop : source_failed / onchain_transport.timeout
le log Transport montre un cooldown rate-limit du RPC public
standard-block-direct
fault avant Stop : source_failed / onchain_transport.rpc_application_error
helius-transaction-hydrated
fault avant Stop : source_failed / onchain_transport.rpc_application_error
Conclusion : le passage du drain par défaut à 10 s reste conservé mais n'est pas une preuve de correction Yellowstone. fix.002 répare les deux gates statiques et expose dans la trace source le contexte interne statique condition des erreurs runtime_invalid. Le prochain live doit fournir cette condition exacte pour Yellowstone et HTTP polling ; aucune conversion générique runtime_invalid -> Stopped n'est autorisée.
pre.009-fix.003 — résultat du gate opérateur fix.002
Le gate opérateur de 0.3.15-pre.009-fix.002 confirme :
audit Rust workspace PASS
audit Markdown PASS (318 tables / 210 fichiers)
cargo check --workspace PASS
Clippy workspace strict -D warnings PASS
tests unitaires Worker PASS : 158 / 158
workspace_logging PASS
tests Worker complets FAIL : 1 canari release_completeness
tests workspace FAIL : même canari Worker
cargo tauri dev lancé et application opérationnelle
L’échec statique restant est exact :
pre_010_production_module_inventory_is_exact
réel : admission.rs, constants.rs, continuity.rs, ...
attendu : admission.rs, continuity.rs, ...
constants.rs est une production source volontaire de fix.002; le canari doit donc l’inclure.
Le live apporte surtout la qualification attendue :
Mainnet / yellowstone-hydrated
route productive via Yellowstone Block + HTTP getBlock
Stop demandé
~5 s plus tard : worker_raw_transaction_ingest.runtime_invalid
condition=source.admission_closed
transport_domain=none
transport_code=none
Mainnet / http-block-polling
route productive via getSlot/getBlocks/getBlock
Stop demandé
~10 ms plus tard : worker_raw_transaction_ingest.runtime_invalid
condition=source.admission_closed
transport_domain=none
transport_code=none
Devnet / yellowstone-hydrated
fault avant Stop lors de SubscribeOpen
source_failed / onchain_transport.grpc_status
OrbitFlare refuse la permission
La cause Mainnet est une race interne commune : le superviseur Worker ferme le receiver d’admission au début du drain alors que run_live_sources n’a pas nécessairement encore relayé le Stop à sa source interne. Un dernier send() voit alors l’admission fermée alors que son stop_receiver local vaut encore false, ce qui fabrique source.admission_closed.
Validation attendue après fix.003 : le drain coopératif ne ferme plus l’admission au début ; il consomme la file jusqu’à destruction naturelle des senders après propagation du Stop. Le hard-close reste dans le chemin shutdown_drain_timeout. Un test unitaire force cette fenêtre de propagation et exige Stopped sans source failure.
pre.010-fix.001 — faux positif du canari de sécurité monitoring
Le gate opérateur de 0.3.15-pre.010 confirme que la tranche compile et que son comportement runtime Mainnet attendu est opérationnel, mais détecte un unique échec déterministe dans le canari Desktop Security :
pre_010_monitoring_projection_is_source_neutral_payload_free_and_javascript_exact
FAIL : monitoring projection exposes forbidden marker raw_transaction
Le marqueur est trop large : route_monitoring.rs doit nécessairement référencer ksp_worker_raw_transaction_ingest_lib et les chemins d'export TypeScript propres à ksp-app-raw-transaction-ingest-desk. Ces identifiants contiennent la chaîne raw_transaction sans exposer aucune donnée RAW.
Le gate opérateur confirme en parallèle :
audit Rust workspace PASS
audit Markdown PASS (318 tables / 212 fichiers)
cargo check --workspace PASS
Clippy workspace strict -D warnings PASS
tests Worker PASS : 160 unitaires + suites d'intégration
Raw Transaction Ingest Desk 1 seul échec : canari desktop_security ci-dessus
workspace all-targets/all-features même échec déterministe
cargo tauri dev lancé et application opérationnelle
Le live Mainnet exécuté pendant ce gate confirme aussi que yellowstone-hydrated et http-block-polling peuvent fonctionner simultanément sur le Store partagé, puis terminer toutes deux en Stopped après Stop ciblé. Aucun fault source.admission_closed n'est réapparu.
Le correctif ne modifie pas la projection runtime. Il sépare le canari en deux niveaux : les marqueurs physiques/secrets (endpoint_url, connection_uri, api_key, source_key, worker_id, x-token) restent interdits dans tout route_monitoring.rs, tandis que les marqueurs RAW (raw_transaction, signature, payload, canonical_bytes, wire_bytes, transaction_bytes) sont interdits dans la seule surface déclarative de RawIngestRouteMonitoringDto. Le test vérifie explicitement les bornes de cette déclaration. Il reste donc strict sur l'IPC sans confondre les noms normaux des crates/bindings avec des champs réellement projetés.
pre.011 — frontend fonctionnel et tracing TypeScript
Base : 0.3.15-pre.010-fix.001, validée par le gate opérateur du 15 septembre 2026. Le correctif de canari desktop_security est confirmé propre ; les audits Rust/Markdown, cargo check --workspace, Clippy strict, les suites Raw Transaction Ingest Desk/Worker et le workspace all-targets/all-features sont passés avant le lancement Tauri. Les smokes opérateur Mainnet montrent également Yellowstone et HTTP Block Polling productifs puis terminalement Stopped après Stop ciblé.
Périmètre pre.011 : frontend uniquement au-dessus du contrat latest-value pre.010.
écoute Tauri ksp-raw-ingest-route-status
resynchronisation get_route_monitoring
Map frontend latest-value par profile_id + route_id
réconciliation des active/last runtimes depuis le snapshot Worker projeté
résumé route : lifecycle / health / activity / persisted / sources / gaps
détail supervision : admission / persistence / outcomes / backpressure / hydration / frontier
sources : active / reconnecting / failed / reconnect / replay / continuity-gap counters
continuité : frontier / open gaps / failed-source reconciliation / future coverage
gaps bornés : range / state / reason / latest repair method
repair totals : replay / redundant coverage / HTTP scan / block fetch / transaction hydration
resync explicite après Start, Stop et action opérateur
Store header dérivé du nombre de Workers actifs, sans exposer de handle Store
Le frontend ne transforme jamais les compteurs, slots ou séquences u64 en number; les chaînes décimales pre.010 sont rendues directement. Les cardinalités u32 restent les seules valeurs numériques de présentation.
Tracing TypeScript ajouté/fermé :
clics génériques sans valeur de contrôle
navigation tabs
sélection profil logique avec counts sûrs
sélection commitment
sélection route de supervision avec route_id/family sûrs
Start/Stop avec route_id/lifecycle
latest-value event avec route_id/sequence/state/terminal
refresh/resync monitoring avec source/counts
IPC via invokeKsp avec command id seulement
Les traces ne sérialisent jamais le DTO monitoring complet et ne journalisent aucun gap slot/range, endpoint, URL, credential, provider secret, source key, WorkerId, signature, transaction bytes ou payload RAW.
Canaris ajoutés :
pre_011_frontend_consumes_latest_value_monitoring_and_renders_full_route_supervision
pre_011_frontend_monitoring_tracing_is_source_neutral_and_does_not_log_raw_material
pre_011_frontend_supervision_closes_planned_ui_without_backend_module_growth
Aucune modification Config, Transport, Store, Worker ou Common RAW n'est introduite par pre.011. Le module Rust de production du Desk reste exactement celui de pre.010; la tranche suivante pre.012 reste dédiée aux races/shutdown/sécurité IPC.
pre.012 — races Start/Stop, shutdown applicatif et sécurité IPC
Base : 0.3.15-pre.011-fix.001, validée par le gate opérateur du 16 septembre 2026. Les audits, cargo check --workspace, Clippy strict, les suites Desk/Worker/workspace et le scénario live multi-route passent ; Yellowstone et HTTP Block Polling restent manipulables simultanément sous charge et le Store partagé ferme seulement après la dernière route.
Périmètre pre.012 : hardening du contrôle Desk uniquement, sans modification des stratégies d'acquisition.
shutdown application
CloseRequested main window intercepté et empêché temporairement
admission de nouveaux Start fermée une seule fois
Stop coopératif demandé à tous les Workers actifs
réservations Starting marquées stop_requested
attente bornée routes + Store avant app_handle.exit
second CloseRequested n'engendre aucun second shutdown
race Start / Stop
Stop sur Starting => marque stop_requested puis attend le cleanup
activation ultérieure => request_stop avant acknowledgement
échec avant activation => rollback retient un terminal logique Stopped
cleanup Desk borné et compatible avec le drain Worker borné
stale inventory / Start
génération sous verrou pendant la préparation synchrone
reconstruction complète Config/Transport à chaque Start
verrou libéré explicitement avant le premier await
admission shutdown revérifiée atomiquement pendant reserve
IPC hostile
StartRequest / StopRequest : deny_unknown_fields
profile_id : non vide, <= 256 octets, sans trim implicite ni contrôle
FrontendLogPayload : deny_unknown_fields
level / target <= 16 octets
message <= 8192 octets et sans caractères de contrôle
frontend : message technique borné à 1024 code units avant IPC
erreurs Tauri : projection domain/code uniquement
Canaris ajoutés/étendus :
pre_012_route_requests_reject_unknown_fields_and_bound_free_form_profile_identity
pre_012_frontend_log_ipc_rejects_unknown_fields_and_unbounded_or_control_messages
pre_012_stop_racing_start_marks_the_reservation_for_cooperative_stop
pre_012_application_shutdown_is_one_shot_and_marks_starting_routes_before_activation
pre_012_window_shutdown_and_start_stop_races_are_bounded_backend_owned
pre_012_hostile_ipc_is_shape_strict_bounded_and_safely_projected
pre_012_race_shutdown_and_ipc_hardening_adds_no_production_module_or_lower_layer_growth
Non-claims : pre.012 ne modifie ni Config, ni Transport, ni Store, ni ksp-worker-raw-transaction-ingest-lib, ni Common RAW. Il n'ajoute aucune orchestration Backfill, aucun scheduler, aucune route et aucune nouvelle donnée frontend. pre.014 reste propriétaire de la fermeture completeness/security cross-layer.
pre.012-fix.001 — future Tauri Start Send
Le gate opérateur de pre.012 a arrêté la tranche sur un défaut de compilation déterministe dans AppState::start_route : le std::sync::MutexGuard<u32> de inventory_generation restait considéré vivant au franchissement du await final, malgré std::mem::drop(generation). Le futur exposé par la commande Tauri start_route ne satisfaisait donc plus la borne Send imposée par tauri::ipc::ResultFutureTag::future. Les audits Rust/Markdown étaient propres et les suites Worker indépendantes restaient vertes, mais cargo check, Clippy, les tests Desk/workspace et cargo tauri dev ne pouvaient pas compiler le Desk.
Le fix ne change aucune sémantique Start/Stop. Lock + revalidation/préparation synchrones sont désormais enfermés dans une portée lexicale let prepared = { ... };. Le MutexGuard est donc détruit structurellement à la fin du bloc avant tout await. Le contrat stale-inventory de pre.012 reste inchangé : la génération demeure verrouillée pendant toute la reconstruction synchrone, mais aucun guard non-Send ne traverse une suspension asynchrone.
Un canari de compilation pre_012_fix_001_start_route_future_is_send_for_tauri_command impose explicitement le type Future<...> + Send au futur retourné par AppState::start_route. Le canari desktop vérifie également la portée lexicale et interdit le retour au simple std::mem::drop(generation) comme preuve de lifetime.
Non-claims : aucune modification de route, Config, Transport, Store, Worker, Common RAW, monitoring, shutdown ou sécurité IPC.
pre.012-fix.002 — fault terminal diagnostiquable sans payload sensible
Le gate opérateur de pre.012-fix.001 compile et teste proprement le Desk, y compris le canari Future + Send. Le live Mainnet révèle toutefois un Worker Yellowstone devenant terminal faulted alors que le Worker HTTP Block Polling continue à produire des getBlock HTTP 200. Aucun WARN source/Transport n'est émis avant le terminal, et le log Desk historique ne conservait que worker_state="faulted"; le fault_domain/fault_code déjà présents dans le snapshot Worker et dans le DTO monitoring étaient donc perdus côté logs opérateur.
Le fix ajoute uniquement une projection de diagnostic terminale source-neutre et bornée dans RouteRuntimeLaunch::monitor. Le log terminal porte désormais l'identité logique sûre de route, worker_state, worker_health, worker_activity, fault_domain, fault_code, les compteurs source_failure_total, store_failure_total, content_conflict_total, les cardinalités source/gap et les booléens de continuité. Aucun endpoint, credential, source key, WorkerId, signature, payload ou octet RAW n'est journalisé.
Ce fix ne change volontairement aucune politique fail-closed : il ne transforme pas un Faulted en succès et ne suppose pas que l'incident observé est un conflit Store ou une panne source. Le prochain live doit permettre de classer exactement la cause avant toute correction comportementale.
pre.012-fix.003 — canari terminal compatible Clippy strict
Le gate opérateur de pre.012-fix.002 confirme que le build normal, les suites Desk/Worker et le live Mainnet sont fonctionnels. Le nouveau diagnostic terminal montre Yellowstone et HTTP Block Polling terminant Stopped, Healthy, sans fault_domain/fault_code ni compteur d'erreur ; l'incident Unhealthy/Faulted précédent ne se reproduit donc pas dans ce run.
Le seul échec du gate est dans cargo clippy --workspace --all-targets --all-features -- -D warnings : le canari pre_012_fix_002_terminal_fault_logging_keeps_safe_route_identity_and_worker_cause_counters utilisait deux assert!(false, ...) dans ses branches de marqueur absent, ce qui déclenche clippy::assertions_on_constants.
Le fix ne modifie aucun code de production. Le canari teste désormais d'abord Option::is_some() puis extrait la valeur avec let-else; la branche impossible retourne seulement après l'assertion dynamique. Aucun panic!, unreachable!, unwrap() ou expect() n'est introduit.
Non-claims : aucune modification du runtime Desk, du monitoring, des routes, de Config, Transport, Store, Worker, Common RAW, acquisition, replay, repair ou politique health/fault.
pre.012-fix.004 — diagnostic sémantique des conflits RAW inter-routes
Le gate opérateur de pre.012-fix.003 compile et teste proprement la tranche puis reproduit deux faults Mainnet distincts sur Yellowstone : un premier terminal content_conflict avec content_conflict_total=13 pendant l'exécution simultanée de Yellowstone + HTTP Block Polling, puis un source_failed / onchain_transport.grpc_backpressure_overflow sur un run ultérieur. Le premier fault ne peut pas être expliqué par le cache de convergence interne d'un Worker : les deux routes Desk sont deux Workers indépendants qui partagent le même Store, et le conflit peut donc être détecté au niveau PostgreSQL lorsqu'une même identité canonique (network, signature) arrive avec un contenu différent.
Le fix ajoute un diagnostic fail-closed au point exact où PostgreSQL possède les deux versions. Avant de renvoyer le même store_api.raw_conflict, le backend journalise uniquement un masque borné et sans valeur métier :
slot_mismatch
block_time_mismatch
format_id_mismatch
format_version_mismatch
content_hash_mismatch
payload_bytes_mismatch
payload_diagnostic_available
transaction_mismatch
meta_mismatch
version_mismatch
transaction_index_mismatch
payload_other_mismatch
meta_mismatch_fields
Pour RAW transaction v1, meta_mismatch_fields compare uniquement une liste fixe de champs connus : err, status, fee, preBalances, postBalances, innerInstructions, logMessages, preTokenBalances, postTokenBalances, rewards, loadedAddresses, returnData, computeUnitsConsumed, costUnits, accounts. Toute extension inconnue est réduite au marqueur statique other; aucun nom arbitraire ni valeur JSON distante n'est copié dans les logs.
Une seconde ligne de diagnostic lit au mieux l'observation durable la plus ancienne de la transaction conflictuelle et compare uniquement la provenance logique sûre avec l'observation entrante : provider, protocol, acquisition_method, endpoint_id, commitment. Signature, hash, payload, bytes, source payload hash, capture session et filter id ne sont jamais journalisés. Une impossibilité de lire cette observation de diagnostic ne modifie pas le fault original.
Ce fix n'altère ni l'identité canonique, ni la comparaison d'égalité, ni la politique de conflit, ni le Store schema, ni la stratégie d'acquisition. serde_json est utilisé uniquement dans le backend PostgreSQL pour classifier les composants du payload RAW v1 déjà canonique au moment d'un conflit.
Le prochain live Yellowstone + HTTP Block Polling doit permettre de distinguer immédiatement un désaccord de slot/block_time, de transaction wire, de transaction index, de version ou d'un sous-ensemble précis de meta (par exemple logMessages ou rewards).
pre.013 — découplage borné Yellowstone Block / HTTP getBlock
Le gate de pre.012-fix.004 est propre sur les nouveaux canaris Store et Worker. Le live Mainnet ne reproduit aucun content_conflict, mais reproduit deux fois un terminal Yellowstone source_failed / onchain_transport.grpc_backpressure_overflow. Les WARN Transport apparaissent à 22:06:52.734796 puis 22:08:39.746262, alors que les Stop Yellowstone n'arrivent qu'à 22:07:10.781900 puis 22:08:51.337483. Le Stop ne crée donc pas l'overflow ; il révèle ensuite le terminal déjà produit par Transport.
La cause est le chemin Yellowstone Block historique entièrement séquentiel :
Block update gRPC
-> await HTTP getBlock
-> await admission de toutes les transactions du bloc
-> seulement ensuite next_update gRPC
Cette source était en outre exclue de uses_hydration(), donc ne recevait aucun quota pending/in-flight du supervisor multi-source. Une queue Transport plus grande ne ferait que retarder le même défaut.
pre.013 corrige le débit sans modifier Transport : Yellowstone Block est désormais une source hydratante pour le partitionnement des budgets existants. Un coordinateur privé de slots borne les pending ; jusqu'au quota in-flight, chaque tâche possédée exécute getBlock puis l'admission complète du bloc. La boucle source reste disponible pour session.next_update() tant qu'une place pending existe. Le slot n'est settled qu'après admission complète. Stop/abort joint toutes les tâches et purge les pending sans faux settlement.
La politique reste fail-closed : aucune hausse de YellowstoneGrpcSessionSettings.update_channel_capacity, aucune queue non bornée, aucun silent drop et aucun masquage de grpc_backpressure_overflow. Si le débit aval reste durablement inférieur à la chaîne malgré la concurrence bornée, une saturation terminale reste correcte et observable.
Canaris ajoutés :
v0_3_15_pre_013_yellowstone_block_hydration_coordinator_is_bounded_before_http_work
v0_3_15_pre_013_yellowstone_block_hydration_is_bounded_concurrent_and_stop_preemptible
v0_3_15_pre_013_yellowstone_block_backpressure_fix_adds_no_public_surface
Aucun type du coordinateur n'est exporté publiquement.
Validation live requise : Yellowstone Mainnet seul pendant une durée supérieure aux ~80 s de reproduction, puis Yellowstone + HTTP Block Polling en parallèle. Le run doit rester Healthy, sans grpc_backpressure_overflow, et les Stop ciblés doivent finir Stopped. Le diagnostic pre.012-fix.004 reste actif si un content_conflict réapparaît.
pre.014 — diagnostic de convergence inter-provider au niveau bloc / logMessages
Le gate opérateur de pre.013 est propre : audits Rust/Markdown, cargo check --workspace, Clippy strict, Worker (161/161 unitaires + suites externes), Desk (50/50 unitaires + suites externes) et workspace passent. Le live Mainnet confirme également l'objectif de pre.013 : aucune occurrence de grpc_backpressure_overflow ni de Yellowstone subscribe update queue overflowed n'est observée dans le run transmis.
Le live reproduit en revanche un unique terminal Yellowstone content_conflict. Le diagnostic Store de pre.012-fix.004 donne exactement :
slot_mismatch=false
block_time_mismatch=false
format_id_mismatch=false
format_version_mismatch=false
transaction_mismatch=false
meta_mismatch=true
version_mismatch=false
transaction_index_mismatch=false
payload_other_mismatch=false
meta_mismatch_fields="logMessages"
La provenance durable classe les deux acquisitions :
stored : solana-public / solana_http / block_polling_get_block / solana_mainnet_public / confirmed
incoming : ys.publicnode:http.publicnode / yellowstone_http / block_subscribe_get_block /
ys.publicnode_solana_mainnet_yellowstone:http.publicnode_solana_mainnet_rpc / confirmed
La transaction canonique elle-même est donc identique ; seule la métadonnée d'exécution meta.logMessages diffère. Le diagnostic existant ne permet toutefois pas encore de savoir si les deux RPC décrivent le même bloc confirmed ou deux forks/vues de bloc différents au même slot.
pre.014 ajoute deux niveaux de diagnostic sans changer la politique de conflit :
Worker / chaque getBlock réussi
source_kind
network
slot
provider
endpoint_id
commitment
parent_slot
block_height
block_identity_fingerprint = SHA-256(domain || blockhash || previousBlockhash || parentSlot || blockHeight)
Store / seulement lors d'un content_conflict
stored_slot / incoming_slot
logMessages state : missing | null | array | other
count de chaque côté
premier index divergent
type statique de la première ligne divergente :
program_invoke | program_success | program_failed | program_log |
program_data | compute_units | log_truncated | other | non_string | missing
longueur de la première ligne divergente
stored_prefix_of_incoming / incoming_prefix_of_stored
has_truncation_marker de chaque côté
Le blockhash, le previousBlockhash, les signatures, les payloads et le texte réel de logMessages ne sont jamais journalisés. Le fingerprint de bloc est irréversible et sert uniquement à comparer deux acquisitions du même slot.
Interprétation du prochain conflit :
même slot + fingerprints différents
=> vues/forks confirmed différents entre providers au moment des getBlock
même slot + même fingerprint + logMessages différents
=> divergence provider/node sur la représentation ou l'enregistrement des logs du même bloc
incoming_prefix_of_stored=true ou stored_prefix_of_incoming=true
=> divergence compatible avec une liste tronquée/incomplète
*_has_truncation_marker=true
=> marqueur explicite de troncature présent dans une des réponses
Non-claims : pre.014 ne retire pas logMessages du contenu canonique, ne choisit aucun provider comme vérité, ne transforme pas content_conflict en succès, ne modifie pas le schema Store et n'expose aucun nouveau type public Worker/Store.
pre.014-fix.001 — observation logMessages tronquée compatible non terminale
Le live pre.014 ferme le diagnostic du conflit Mainnet observé au slot 447781296. HTTP Block Polling et Yellowstone Block Hydration ont produit la même identité de bloc (parent_slot=447781295, block_height=425822496, même fingerprint), la même transaction, le même index et les mêmes autres métadonnées. La seule divergence est meta.logMessages.
Le canonique déjà stocké contient 176 lignes sans marqueur de troncature. L'acquisition entrante contient 118 lignes et un marqueur exact Log truncated au premier point divergent. Le diagnostic prouve que toutes les lignes antérieures à ce marqueur sont identiques. Le défaut n'est donc ni un fork ni un changement de transaction : c'est une représentation RPC explicitement tronquée du même résultat d'exécution.
fix.001 ajoute une compatibilité volontairement asymétrique et étroite dans le backend PostgreSQL :
canonique déjà complet
+ entrant explicitement tronqué et moins complet au-delà du marqueur
+ mêmes network/signature/slot/block_time/format
+ mêmes transaction/version/transactionIndex
+ mêmes champs meta hors logMessages
+ un seul marqueur exact "Log truncated" côté entrant
+ préfixe avant marqueur identique
+ préfixe exact jusqu’au marqueur ; le matériel après le marqueur n’est pas utilisé pour prouver la complétude
=> AlreadyPresent + observation persistée
=> aucun content_conflict
=> Worker continue
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.
pre.014-fix.003 — resserrement du canari de non-réécriture canonique
Le gate opérateur de pre.014-fix.002 confirme la correction de typage : les audits statiques sont propres, cargo check --workspace et Clippy strict passent, les 75/75 tests unitaires ksp-store-postgres-lib passent, puis l'unique échec apparaît dans tests/hardening_completeness.rs. Le canari v0_3_15_pre_014_fix_001_truncated_log_compatibility_is_narrow_and_keeps_canonical_content cherchait la chaîne SQL UPDATE ksp_raw_transactions SET payload dans l'intégralité de src/raw_transaction.rs. Or cette chaîne existe légitimement dans la transition de rétention/archive historique du backend et n'appartient pas au chemin CompatibleLessComplete.
fix.003 resserre donc uniquement ce canari sur le corps de compare_existing_transaction(), jusqu'à la frontière du helper raw_transaction_incoming_truncated_log_messages_compatible(). Dans cette portion exacte, le test continue d'exiger le retour ExistingTransactionMatch::ActiveIncomingTruncatedLogs et interdit toute occurrence d'UPDATE ... payload ou de DELETE FROM ksp_raw_transactions. Le comportement production, le schéma SQL, la compatibilité logMessages, les outcomes Store et le Worker restent byte-for-byte inchangés par ce fix.
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.