v0.2.1-pre.005
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/008-V0_2_1_ONCHAIN_HTTP_PLAN.md -->
|
||||
<!-- version: 5 -->
|
||||
<!-- version: 6 -->
|
||||
|
||||
# `0.2.1-pre.001` — plan `ksp-onchain-transport-lib` HTTP Solana foundation
|
||||
|
||||
@@ -867,15 +867,15 @@ La release peut devenir stable seulement si :
|
||||
|
||||
## 22. Prévision souple des prereleases de la `0.2.1` réduite
|
||||
|
||||
| Tranche | Objectif |
|
||||
|-----------|----------------------------------------------------------------------------------------------------------------------|
|
||||
| `pre.001` | audit KSP + bot3 + docs officielles, matrice 52+14, architecture, split et sizing |
|
||||
| `pre.002` | **réalisé** : crate/workspace, codes erreur, settings/validation, JSON-RPC, descriptors/status, base Logging |
|
||||
| `pre.003` | **réalisé** : endpoint client + pool logique + rôles/capabilities + priorité/fairness/fallback + snapshots sûrs |
|
||||
| `pre.004` | **réalisé** : RPS/burst/concurrence/cooldown + deadline commune + retry/backoff + classification retry/no-resend |
|
||||
| `pre.005` | méthodes canari `getHealth`, `getVersion`, `getGenesisHash`, `getBalance` + fixtures déterministes |
|
||||
| `pre.006` | `std.transport` schema/document/example + registry Config + adapter Config -> Transport + sensibilité/env tests |
|
||||
| `pre.007` | completeness/canaries, smoke opt-in, `cargo tree`, README/USAGE, docs finales, prompt `0.2.2`, préparation `rel.001` |
|
||||
| Tranche | Objectif |
|
||||
|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `pre.001` | audit KSP + bot3 + docs officielles, matrice 52+14, architecture, split et sizing |
|
||||
| `pre.002` | **réalisé** : crate/workspace, codes erreur, settings/validation, JSON-RPC, descriptors/status, base Logging |
|
||||
| `pre.003` | **réalisé** : endpoint client + pool logique + rôles/capabilities + priorité/fairness/fallback + snapshots sûrs |
|
||||
| `pre.004` | **réalisé** : RPS/burst/concurrence/cooldown + deadline commune + retry/backoff + classification retry/no-resend |
|
||||
| `pre.005` | **réalisé** : exécution HTTP JSON-RPC + `getHealth`, `getVersion`, `getGenesisHash`, `getBalance` + fixtures déterministes + centralisation des canaries workspace dans Core |
|
||||
| `pre.006` | `std.transport` schema/document/example + registry Config + adapter Config -> Transport + sensibilité/env tests |
|
||||
| `pre.007` | completeness/canaries, smoke opt-in, `cargo tree`, README/USAGE, docs finales, prompt `0.2.2`, préparation `rel.001` |
|
||||
|
||||
Ce découpage est révisable si une tranche dépasse le budget ; la release réduite, contrairement au scope initial, reste raisonnablement clôturable dans la session.
|
||||
|
||||
@@ -927,13 +927,28 @@ Restent volontairement à `pre.004` : token bucket RPS/burst, semaphore de concu
|
||||
- snapshots sûrs enrichis avec availability de rôle, limites, requêtes en vol, cooldown restant et compteurs success/failure/rate-limit, sans URL ni secret ;
|
||||
- transitions passives `Available -> Degraded/RateLimited` sur observations runtime et retour `Degraded -> Available` après succès ;
|
||||
- policy centralisée `evaluate_transport_retry()` : backoff exponentiel borné, budget `max_retries`, causes transport explicitement retryables, RPC application errors hors retry, et respect strict de `TransportRetryClass::NeverAfterDispatch` pour empêcher un resend automatique après dispatch ambigu ;
|
||||
- `tokio` est consommé directement par Transport uniquement via la dépendance workspace avec feature locale `sync`; `time`/runtime restent fournis par le feature-set workspace existant ;
|
||||
- après `pre.004-fix.001/.002`, les features d’usage sont activées localement par crate : Transport porte `reqwest/rustls`, `serde/derive`, `tokio/macros+sync+time` et `tokio/rt` seulement en dev ; le root conserve version/default-features sans activation de features d’usage ;
|
||||
- la suite Transport compte désormais **72 tests déclarés**, avec preuves supplémentaires sur limiter, concurrence, cooldown, deadline, fallback runtime, santé passive, policy de retry et consommation publique de l'admission async.
|
||||
|
||||
La tranche ne parse pas encore elle-même le header HTTP `Retry-After` et n'exécute pas de POST JSON-RPC : ces signaux seront raccordés à l'exécuteur HTTP avec les méthodes canari de `pre.005`.
|
||||
|
||||
Restent à `pre.005` : exécution HTTP JSON-RPC réelle et wrappers typés `getHealth`, `getVersion`, `getGenesisHash`, `getBalance`, avec fixtures déterministes et raccordement des erreurs HTTP/429/timeout à la résilience maintenant disponible.
|
||||
|
||||
### 22.4 État après `0.2.1-pre.005`
|
||||
|
||||
`pre.005` matérialise la première exécution réseau HTTP complète et les quatre canaris typés de la release :
|
||||
|
||||
- `workspace.package.version = 0.2.1-pre.5` ;
|
||||
- exécuteur générique `execute_standard_rpc` : allocation d'id JSON-RPC KSP, admission via pool, POST `application/json`, deadline commune, mapping connexion/timeout/status HTTP, parsing JSON-RPC et mise à jour de santé passive ;
|
||||
- HTTP `429` raccordé au cooldown de rôle et à la policy de retry avec parsing défensif de `Retry-After` sous forme delta-seconds ; statuts temporaires `408/500/502/503/504` raccordés au retry borné ;
|
||||
- les retries réacquièrent capacité RPS/concurrence et restent bornés par la même deadline ; la classification `NeverAfterDispatch` reste centralisée pour empêcher les futurs write/submission de se resoumettre après ambiguïté ;
|
||||
- wrappers typés `getHealth`, `getGenesisHash`, `getVersion`, `getBalance`, avec `ksp_core_lib::Pubkey`, commitment/minContextSlot optionnels, DTO de contexte/balance/version et validation de forme ;
|
||||
- fixtures JSON déterministes et serveur HTTP local de tests : les canaris prouvent le POST réel et les formes request/response ; tests supplémentaires sur récupération après 429 et timeout reqwest ;
|
||||
- les deux canaries de dépendances générales quittent `ksp-onchain-transport-lib/tests/dependency_boundary.rs` et sont centralisées sous `ksp-core-lib/tests/workspace_dependencies.rs`, conformément à `DEP-CARGO-007` ;
|
||||
- Transport compte désormais **78 tests déclarés** ; Core porte 2 canaries workspace supplémentaires dans sa surface d'intégration.
|
||||
|
||||
Restent à `pre.006` : document/schema/exemple `std.transport`, enregistrement Config, adapter Config -> Transport et tests de sensibilité/provenance/env.
|
||||
|
||||
## 23. Séquence `0.2.x` recalibrée
|
||||
|
||||
```text
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/RULES_DEPENDENCIES.md -->
|
||||
<!-- version: 12 -->
|
||||
<!-- version: 13 -->
|
||||
|
||||
# Règles des dépendances KSP
|
||||
|
||||
@@ -31,6 +31,7 @@ Elles complètent les règles Rust générales et le graphe de `docs/architectur
|
||||
- **DEP-CARGO-004** — Lorsqu'une génération majeure/mineure compatible est retenue, KSP exprime explicitement l'intention sous forme caret `^M.m` (par exemple `^4.3`) plutôt qu'avec une écriture patch telle que `4.3.0`. Même si Cargo interprète aussi par défaut cette dernière comme une contrainte compatible caret, KSP normalise la syntaxe pour rendre l'intention manifeste. Un pin exact `=M.m.p` ou un bornage différent requiert une justification explicite.
|
||||
- **DEP-CARGO-005** — Le `Cargo.lock` résout la version patch concrète à l'intérieur de la contrainte du workspace ; cette résolution ne remplace pas la politique de version déclarée dans le manifeste racine.
|
||||
- **DEP-CARGO-006** — Lorsqu'une feature externe n'est nécessaire qu'aux tests/benchmarks/examples d'une crate, son activation appartient à la section de dépendances de développement correspondante plutôt qu'aux dépendances de production. L'unification des features effectuée par Cargo lors d'un build ne transfère pas cet ownership vers le `Cargo.toml` racine.
|
||||
- **DEP-CARGO-007** — Les canaries qui inspectent une politique générale du workspace ou plusieurs manifests membres appartiennent à une surface de gouvernance/fondation (actuellement les tests de `ksp-core-lib` tant qu'aucun outil d'audit dédié n'existe). Une crate métier spécialisée conserve uniquement les tests de frontière propres à son domaine et ne devient pas propriétaire d'une règle globale du workspace.
|
||||
|
||||
## Codecs wire et cohérence des versions
|
||||
|
||||
|
||||
Reference in New Issue
Block a user