Files
khadhroony-solana-project/docs/validation/006-V0_2_3_HTTP_TRANSACTIONS.md
2026-08-18 17:33:46 +02:00

7.8 KiB

Validation candidate 0.2.3 — HTTP Transactions

Objet

Cette matrice porte la clôture candidate de 0.2.3 — HTTP Transactions.

Elle complète le réaudit transversal 005-V0_2_3_KSP_TRANSPORT_007_RETRO_AUDIT.md, qui vérifie la complétude de requête/réponse des 37 wrappers HTTP typés courants.

La publication stable reste réservée à 0.2.3-rel.001.

Réaudit final de l'inventaire

Dernier contrôle effectué le 18 août 2026 contre :

https://solana.com/docs/rpc/http
https://solana.com/docs/rpc/deprecated/confirmtransaction
https://solana.com/docs/rpc/json-structures

L'inventaire reste :

52 méthodes HTTP courantes
14 méthodes historiques Deprecated

Partition KSP candidate :

0.2.1 foundation             4
0.2.2 Accounts/Tokens/Cluster 22
0.2.3 Transactions            11
surface typée candidate       37
0.2.4 Blocks/Economics restant 15

Aucun recalibrage de HttpRpcCoverageRelease n'est nécessaire.

Surface Transactions candidate

Méthode Classe KSP Contrat de clôture principal
getFeeForMessage Read / RetrySafe message base64 opaque, contexte, fee nullable
getLatestBlockhash Read / RetrySafe contexte, blockhash non vide, lastValidBlockHeight
getRecentPrioritizationFees Read / RetrySafe comptes optionnels <= 128, ordre serveur
getSignaturesForAddress Read / RetrySafe pagination before/until/1..=1000, newest-first, transactionIndex optionnel
getSignatureStatuses Read / RetrySafe <= 256, liste vide runtime, null positionnels, searchTransactionHistory
getTransaction Read / RetrySafe config moderne complète + bare encoding deprecated, encodings/version/meta/index lossless
getTransactionCount Read / RetrySafe contexte + u64
isBlockhashValid Read / RetrySafe blockhash opaque + contexte + bool
requestAirdrop WriteSubmission / NeverAfterDispatch commitment + recentBlockhash runtime, signature, aucune resoumission après dispatch ambigu
sendTransaction WriteSubmission / NeverAfterDispatch base58/base64 + toutes options, maxRetries node-side, aucune resoumission après dispatch ambigu
simulateTransaction Simulation / RetrySafe config complète, invariants locaux, résultat riche lossless

Classification exacte :

8 Read            / RetrySafe
2 WriteSubmission / NeverAfterDispatch
1 Simulation      / RetrySafe

Complétude KSP-TRANSPORT-007

Le réaudit pre.008 conclut 37/37 conformes sans remédiation fonctionnelle.

Points particulièrement sensibles conservés :

  • encodings Account/Transaction legacy encore supportés ;
  • getLeaderSchedule et getTransaction avec leurs formes de requête distinctes ;
  • transactionIndex courant ;
  • requestAirdrop.recentBlockhash runtime ;
  • sendTransaction.maxRetries distinct du retry HTTP KSP ;
  • simulateTransaction.accounts avec encodings de retour supportés et rejet local de binary/base58 ;
  • résultats wire riches conservés sans introduire de dépendance SDK/RPC haut niveau.

Résilience et no-resend

Les deux writes utilisent le descriptor central WriteSubmission / NeverAfterDispatch.

Les fixtures end-to-end déjà livrées prouvent :

HTTP 429 après dispatch  -> une seule requête
HTTP 503 après dispatch  -> une seule requête
timeout après dispatch   -> une seule requête
NotDispatched prouvé     -> retry/fallback central autorisé

simulateTransaction reste retry-safe et possède un scénario déterministe HTTP 503 -> succès.

Canaries déterministes

La candidate conserve :

current registry      == 52
historical registry   == 14
V0_2_1 exact          == 4
V0_2_2 exact          == 22
V0_2_3 exact          == 11
V0_2_4 restant        == 15
KSP-TRANSPORT-007     == 37 wrappers courants audités

À la base validée pre.008, l'opérateur a confirmé :

182 tests unitaires Transport        passed
19 tests public API                  passed
14 tests release completeness        passed
1 smoke Transport live               ignored par défaut
0 failure
0 warning clippy signalé

Smoke Devnet Transport pur

pre.009 étend le smoke Transport existant sans créer de nouvelle ownership boundary.

La séquence reste read-only :

settings programmatiques
  -> getAccountInfo
  -> getTokenAccountsByOwner
  -> getEpochInfo
  -> getVoteAccounts
  -> getLatestBlockhash
  -> isBlockhashValid
  -> getTransactionCount

La branche Transaction ne déclenche ni requestAirdrop, ni sendTransaction, ni simulation nécessitant une transaction sérialisée. Les fixtures locales restent la preuve déterministe complète des 11 wrappers.

Commande opt-in :

cargo test -p ksp-onchain-transport-lib --test transport_devnet_smoke -- --ignored --nocapture

Le smoke historique Config -> Transport reste séparé et transitoire :

cargo test -p ksp-config-lib --test transport_devnet_smoke -- --ignored --nocapture

Frontières et dépendances attendues

À clôture :

ksp-config-lib -> ksp-onchain-transport-lib
ksp-onchain-transport-lib -> ksp-core-lib
ksp-onchain-transport-lib -> ksp-logging-lib
ksp-onchain-transport-lib -X-> ksp-config-lib
ksp-onchain-transport-lib -X-> Store
ksp-onchain-transport-lib -X-> Program
ksp-onchain-transport-lib -X-> tracing direct

Aucune nouvelle dépendance base64, bs58, wincode, solana-client ou client RPC haut niveau n'est introduite par 0.2.3.

Validations de candidate à exécuter

La clôture opérateur de pre.009 doit exécuter :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-onchain-transport-lib
cargo test -p ksp-config-lib
cargo test -p ksp-core-lib
cargo test -p ksp-app-config-desk
cargo test --workspace

cargo tree -p ksp-onchain-transport-lib
cargo tree -p ksp-onchain-transport-lib -d
cargo tree -p ksp-onchain-transport-lib -e features
cargo tree -p ksp-onchain-transport-lib -e normal
cargo tree -p ksp-config-lib
cargo tree -p ksp-config-lib -d
cargo tree -p ksp-config-lib -e features
cargo tree -p ksp-config-lib -e normal

cargo test -p ksp-onchain-transport-lib --test transport_devnet_smoke -- --ignored --nocapture
cargo test -p ksp-config-lib --test transport_devnet_smoke -- --ignored --nocapture

Aucune de ces commandes n'est considérée réussie avant preuve opérateur.

Passage à rel.001

Si la candidate est propre, 0.2.3-rel.001 doit rester strictement publicationnelle :

workspace.package.version -> 0.2.3
ROADMAP : 0.2.3 -> [X]
CHANGELOG : synthèse stable 0.2.3
plan 010 / validation 006 : clôture avec preuves opérateur
deltas/0.2.3/rel.001.md
commit v0.2.3-rel.001
tag stable v0.2.3 après validation

Aucune nouvelle méthode HTTP, aucun nouveau DTO et aucun nouveau comportement runtime ne doivent être introduits pendant rel.001.