v0.3.6-pre.005
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/027-V0_3_6_JOB_API_BACKFILL_PLAN.md -->
|
||||
<!-- version: 7 -->
|
||||
<!-- version: 8 -->
|
||||
|
||||
# Plan v0.3.6 — Job API et premier backfill RAW
|
||||
|
||||
@@ -226,7 +226,11 @@ Chaque transaction disponible produit :
|
||||
- une `RawAcquisitionProvenance` avec fournisseur, protocole Solana HTTP JSON-RPC, méthode `getTransaction`, endpoint sûr, engagement, instant de réception et `JobId` comme session de capture ;
|
||||
- une `RawTransactionObservation` dont la clé déterministe est un SHA-256 domain-separated du `JobId`, du fingerprint de scope, de la signature, du fournisseur, de l'endpoint, de l'engagement et de la version du contrat d'acquisition.
|
||||
|
||||
Une reprise du même Job par le même endpoint retrouve donc l'observation. Un autre endpoint constitue une nouvelle acquisition légitime. Une différence de payload canonique pour la même référence reste un conflit Store, jamais un skip.
|
||||
L'identité transactionnelle logique est donc strictement `(RawNetworkId, signature)` : `mainnet`, `devnet`, `testnet`, `localnet`, `synthetic` ou tout autre réseau logique validé constituent des namespaces distincts. Le rôle Transport, le provider, l'endpoint et le protocole HTTP/WS/gRPC n'entrent jamais dans cette identité. Plusieurs acquisitions du même réseau et de la même signature convergent vers la même transaction canonique, quelle que soit leur voie d'acquisition ; elles peuvent en revanche produire des observations de provenance distinctes.
|
||||
|
||||
Le backend PostgreSQL actuel lie un Store physique à exactement un `RawNetworkId` via `ksp_store_identity`. Son index physique peut donc rester local au namespace réseau. Tout backend futur capable d'héberger plusieurs réseaux dans un même namespace physique doit inclure le réseau dans sa clé, sa partition ou un mécanisme équivalent garantissant la même identité logique `(network, signature)`.
|
||||
|
||||
Le fingerprint de scope inclut le réseau et les paramètres sémantiques, mais exclut rôle HTTP, provider, endpoint et protocole. Une reprise du même Job par le même endpoint retrouve donc l'observation. Un autre endpoint constitue une nouvelle acquisition légitime. Une différence de payload canonique pour la même référence reste un conflit Store, jamais un skip.
|
||||
|
||||
## 13. Persistance et idempotence
|
||||
|
||||
@@ -422,17 +426,21 @@ Le gate opérateur de `pre.003` confirme `cargo fmt`, les audits Rust/Markdown e
|
||||
|
||||
### `pre.004` — Provenance Transport observée
|
||||
|
||||
**Statut : matérialisé ; gate opérateur à rejouer.**
|
||||
**Statut : clôturé ; gate opérateur vert.**
|
||||
|
||||
Budget cible : **15-20 min**. Entrée : besoin de provenance confirmé par le plan et gate `pre.003-fix.001` vert. La tranche ajoute `HttpObservedValue<T>` comme enveloppe typée ne conservant que la valeur, le nom sûr de l'endpoint victorieux et son provider. `HttpTransportPool::get_transaction_observed` reprend exactement les validations et le moteur `execute_standard_rpc` existants ; le moteur commun possède désormais une voie interne observée et l'API historique continue à ne retourner que la valeur.
|
||||
|
||||
Les tests couvrent le succès direct `null`, la surface publique et surtout un retry `429` entre deux endpoints de même priorité : le résultat observé rapporte le second endpoint/provider qui a réellement produit la réponse, jamais le candidat initial. URL, headers et body HTTP brut restent absents du contrat, et le `Debug` de l'enveloppe ne rend pas la valeur typée. Sortie attendue après gate : routage/retry/provenance Transport verts sans nouvelle dépendance ni changement de politique.
|
||||
Les tests couvrent le succès direct `null`, la surface publique et surtout un retry `429` entre deux endpoints de même priorité : le résultat observé rapporte le second endpoint/provider qui a réellement produit la réponse, jamais le candidat initial. URL, headers et body HTTP brut restent absents du contrat, et le `Debug` de l'enveloppe ne rend pas la valeur typée. Le gate opérateur est vert : audits, `cargo check`, Clippy, 385 unitaires Transport, 50 canaries publiques, 43 canaries de complétude, doctests et arbres Cargo passent sans nouvelle dépendance/feature Transport.
|
||||
|
||||
### `pre.005` — Fondation Backfill et découverte
|
||||
|
||||
**Statut : planifié.**
|
||||
**Statut : matérialisé ; gate opérateur à rejouer.**
|
||||
|
||||
Budget cible : **15-20 min**. Entrée : Transport observé stable. Créer la crate, les requêtes, scopes, validations, candidats et pagination. Sortie : fixtures latest, before, after et explicite, avec déduplication stable.
|
||||
Budget cible : **15-20 min**. Entrée : Transport observé stable et gate `pre.004` vert. La tranche crée `ksp-job-backfill-lib` avec dépendances directes Job API, Core, Logging, Onchain Transport, Store façade sans feature backend imposée et SHA-256 déjà centralisé au workspace ; Tokio reste uniquement une dev-dependency pour les tests async de cette tranche.
|
||||
|
||||
La requête impose explicitement `JobId`, `RawNetworkId`, rôle HTTP, engagement `Confirmed|Finalized`, scope, page size `1..=1000`, pages `1..=10000`, candidats `1..=10000`, future concurrence d'hydratation `1..=64` et `min_context_slot` seulement pour les scopes adresse. Les quatre scopes sont matérialisés. Les signatures explicites sont bornées, Base58-shaped et dédupliquées à première occurrence ; le décodage exact vers 64 octets reste volontairement `pre.006`.
|
||||
|
||||
`BackfillCandidateIdentity` est explicitement `(RawNetworkId, BackfillSignature)` ; rôle/provider/endpoint/protocole sont exclus du fingerprint de scope et ne peuvent donc pas devenir une identité transactionnelle. La découverte réelle appelle uniquement `HttpTransportPool::get_signatures_for_address`, sans client, retry, pacing ou endpoint policy dans Job. Latest/Before paginent par `before`, After conserve la fenêtre plus récente la plus proche de l'ancre via `until`, et les limites de pages produisent un résultat partiel observable plutôt qu'une fausse complétion. Les doubles déterministes restent privés aux tests. La tranche matérialise 11 tests unitaires et 6 canaries d’intégration ; leur exécution Cargo reste une preuve opérateur. Sortie attendue après gate : latest, before, after et explicite, déduplication stable, frontières partielles et firewall de dépendances verts.
|
||||
|
||||
### `pre.006` — Conversion RAW v1 et provenance
|
||||
|
||||
|
||||
Reference in New Issue
Block a user