7.1 KiB
Delta 0.3.14-pre.007 — hydration des références connues
Base requise
0.3.14-pre.006
workspace.package.version = 0.3.14-pre.6
deltas/0.3.14/pre.006.md présent
Gate de la base
Le gate opérateur de 0.3.14-pre.006 est validé avant ouverture de cette tranche :
cargo fmt --all : PASS
cargo fmt --all -- --check : PASS
audit Rust workspace rules : PASS
audit Markdown tables : PASS
cargo check --workspace : PASS
cargo clippy --workspace --all-targets --all-features -- -D warnings : PASS
cargo test -p ksp-worker-raw-transaction-ingest-lib --all-targets --all-features : PASS
Le gate Worker comprend notamment :
129 unit tests : PASS
cross_layer_completeness : 8 PASS
dependency_boundary : 19 PASS
hardening : 31 PASS
public_api : 20 PASS
release_completeness : 8 PASS
Objectif
Implémenter strictement la tranche pre.007 du plan 035 :
réutiliser getTransaction observed pour une référence déjà connue
réutiliser le registre global de coalescence network/signature/commitment existant
ne créer aucun second registre d'hydration
représenter getTransaction = null comme une obligation Missing, jamais comme une preuve d'absence
conserver exactement le slot déjà observé avec la référence
préférer le bloc de ce slot lorsque le même rôle HTTP expose getBlock
ne pas déclencher encore la réconciliation du gap-ledger ni modifier le supervisor
ne pas ajouter de retry réseau Worker
Obligation de référence connue
continuity.rs matérialise un contrat privé :
RawTransactionIngestKnownReferenceObligation
reference : network + signature déjà observés
slot : slot déjà observé
commitment : Confirmed ou Finalized exact
Le contrat refuse Processed et ne contient aucun état « absent ». Il ne peut donc pas convertir une réponse HTTP null en preuve que la transaction n'existait pas.
Cette obligation reste distincte de TargetCoverage : KnownReferences ne devient toujours jamais une configured target coverage.
Réutilisation de la coalescence globale
Le chemin productif existant reste fondé sur :
RawTransactionIngestGlobalHydrationRegistry
RawTransactionIngestHydrationKey
network
signature
commitment
fetch_hydration_shared(...)
fetch_hydration(...)
HttpTransportPool::get_transaction_observed(...)
Aucun registre KnownReferenceHydrationRegistry, semaphore parallèle ou second fanout HTTP n'est ajouté.
Deux demandes concurrentes portant la même clé de référence partagent donc toujours le leader/follower global déjà présent depuis 0.3.13.
Résolution de l'hydration
La qualification après getTransaction observed devient explicite :
Available(ingress)
Missing {
obligation,
disposition
}
Available réutilise exactement finalize_hydration et le pipeline central Common RAW -> admission -> Store existant.
Missing conserve la référence et son slot. Il ne produit aucun ingress et ne ferme aucune obligation de continuité.
Le coordinator nominal existant conserve son comportement stable jusqu'à pre.008 : lorsqu'une notification live ordinaire hydrate vers null, son pending de processing est soldé comme auparavant. La nouvelle représentation Missing est toutefois la primitive réutilisable par la réconciliation ; pre.008 décidera explicitement de la conservation dans le gap-ledger au lieu de confondre ce résultat avec une absence prouvée.
Préférence bloc du slot
Après un getTransaction = null, aucune requête bloc n'est lancée automatiquement dans cette tranche.
Le rôle HTTP exact est inspecté sans I/O supplémentaire :
getBlock supporté sur le même rôle
-> PreferBlockSlot
getBlock non supporté
-> AwaitCoverage
PreferBlockSlot signifie uniquement que le slot déjà connu est la prochaine primitive de matériau à privilégier lors de la réconciliation. Cela n'autorise ni scan historique, ni broadening du scope filtré, ni ingestion de transactions inconnues du bloc.
Le scan/discovery borné de pre.006 et cette préférence de matériau restent séparés jusqu'à l'unification pre.008.
Tests ajoutés
Les unit tests couvrent :
obligation connue conservant exactement reference/slot/commitment
rejet du commitment Processed
coalescence de deux hydrations concurrentes vers une seule requête getTransaction
résolution Available vers le pipeline Common RAW existant
getTransaction = null sans getBlock -> Missing/AwaitCoverage
getTransaction = null avec getBlock sur le même rôle -> Missing/PreferBlockSlot
Les canaris hardening et release_completeness garantissent en plus :
un seul RawTransactionIngestGlobalHydrationRegistry
aucun second KnownReferenceHydrationRegistry
réutilisation de fetch_hydration_shared et get_transaction_observed
aucune nouvelle surface publique
aucune responsabilité lower-case repair dans crate-root
Hors périmètre inchangé
aucune conservation active du Missing dans le gap-ledger avant pre.008
aucun getBlock fallback exécuté automatiquement dans cette tranche
aucune modification du supervisor source-loss
aucune modification de la health policy
aucun retry réseau Worker parallèle à Transport
aucune source/provider supplémentaire
aucun EARLY/shred adapter
aucun backfill historique caller-driven
Fichiers ajoutés
deltas/0.3.14/pre.007.md
Fichiers modifiés
Cargo.toml
crates/ksp-worker-raw-transaction-ingest-lib/src/continuity.rs
crates/ksp-worker-raw-transaction-ingest-lib/src/lib.rs
crates/ksp-worker-raw-transaction-ingest-lib/src/runtime_resources.rs
crates/ksp-worker-raw-transaction-ingest-lib/tests/hardening.rs
crates/ksp-worker-raw-transaction-ingest-lib/tests/release_completeness.rs
crates/ksp-worker-raw-transaction-ingest-lib/unit_tests/continuity.rs
crates/ksp-worker-raw-transaction-ingest-lib/unit_tests/runtime_resources.rs
Fichiers supprimés
aucun
Version Cargo
Conformément à VER-ID-009 :
header Cargo.toml : 573 -> 574
workspace.package.version : 0.3.14-pre.6 -> 0.3.14-pre.7
Versions des fichiers modifiés :
continuity.rs : 6 -> 7
lib.rs : 30 -> 31
runtime_resources.rs : 32 -> 33
unit_tests/continuity.rs : 4 -> 5
unit_tests/runtime_resources.rs : 26 -> 27
tests/hardening.rs : 30 -> 31
tests/release_completeness.rs : 25 -> 26
Validation exécutée dans l'environnement de préparation
python3 scripts/audit_rust_workspace_rules.py : PASS
python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas : PASS
Les gates Cargo ne sont pas déclarés PASS dans l'environnement de préparation lorsqu'ils ne peuvent pas y être exécutés. Ils restent obligatoires côté opérateur avant pre.008.
Prochaine tranche
pre.008 : unification replay/redondance/discovery HTTP/hydration dans le ledger, calcul du continuity frontier et remplacement de la terminalité « first source failure » uniquement lorsqu'une TargetCoverage présente et future est explicitement prouvée ; aucun respawn Worker d'une source Transport.