Files
khadhroony-solana-project/deltas/0.3.3/pre.009.md
2026-08-30 14:29:33 +02:00

185 lines
5.9 KiB
Markdown

<!-- file: deltas/0.3.3/pre.009.md -->
<!-- version: 1 -->
# Delta `0.3.3-pre.009` — preuve PostgreSQL live complète RawTransaction
## 1. Base et gate d'entrée
Base opérateur obligatoire :
```text
0.3.3-pre.8.fix.1
```
Le gate opérateur fourni le 2026-08-30 est entièrement propre : audits Rust/Markdown, `cargo check --workspace`, Clippy all-targets sans warning, tests Store API/façade/PostgreSQL/Config et `ksp-store-lib --no-default-features` passent. `pre.008-fix.001` est donc acquise.
## 2. Version
```text
workspace.package.version = 0.3.3-pre.9
```
## 3. Nouveau test PostgreSQL réel
La tranche ajoute :
```text
crates/ksp-store-postgres-lib/tests/postgres_raw_transaction_live.rs
```
Le test est `#[ignore]`, lit une URI PostgreSQL dédiée uniquement sur `stdin`, ne l'affiche jamais et refuse de démarrer lorsqu'une table KSP V000/V001 existe déjà. Il ne nettoie que le schéma qu'il a prouvé absent avant son propre bootstrap.
Il refuse PostgreSQL < 15 comme la preuve fondation existante.
## 4. Migration, identité réseau et schema update
La preuve couvre :
- bootstrap V000 + V001 sur base vide ;
- health Ready avec migration 1 ;
- refus d'une réouverture sous un autre `RawNetworkId` ;
- réouverture idempotente ;
- suppression contrôlée de `ix_ksp_raw_transactions_slot_signature` ;
- `schema_autoupdate=false` qui bloque le drift ;
- `schema_autoupdate=true` qui recrée et revalide l'index manquant.
Aucune ressource de migration n'est modifiée et aucun historique n'est réécrit.
## 5. Écriture, idempotence, concurrence et rollback
Le live couvre :
- canonical + observation atomiques ;
- get canonical exact ;
- observation round-trip exact avec provenance complète ;
- deux acquisitions identiques en vraies tâches concurrentes : un `Inserted`, un `AlreadyPresent` ;
- deux acquisitions divergentes sous la même signature : un gagnant et un `Conflict` ;
- vérification qu'une seule observation du duel divergent est durable ;
- observation supplémentaire `Inserted` puis `AlreadyPresent` ;
- même observation key divergente -> `Conflict` ;
- collision observation pendant une nouvelle acquisition -> rollback du canonical nouvellement tenté.
## 6. Pagination
Le test insère cinq signatures sur trois slots, dont deux paires ex æquo, et prouve :
```text
Ascending 50, 51, 52, 53, 54
Descending 54, 53, 52, 51, 50
page size 2
```
Il rejoue ensuite le cursor V1 sous :
- direction différente ;
- range différente.
Les deux cas doivent être `QueryInvalid`.
## 7. Rétention et rehydrate
La preuve couvre :
- compare mismatch observable ;
- `Full -> Archived` et lecture exacte depuis archive ;
- idempotence `AlreadyAtTarget` ;
- `Archived -> Purged` ;
- `get -> None` et tombstone minimal exact ;
- acquisition normale sur tombstone -> `SkippedPurged/NotRecorded` ;
- ForceRehydrate divergent -> `Conflict` sans mutation ;
- ForceRehydrate compatible -> `Rehydrated/Inserted` ;
- `Full -> Compacted` rejeté par `RetentionCompactionUnsupported` sans changement d'état ;
- deux archives concurrentes puis deux purges concurrentes : un `Applied` et un `AlreadyAtTarget` par race ;
- rehydrate après la race purge.
## 8. Cancellation réelle
Le test crée une observation durable, la verrouille via une transaction PostgreSQL administrateur, puis démarre une nouvelle acquisition qui :
1. insère son canonical dans sa transaction non committée ;
2. bloque sur la collision de l'observation verrouillée ;
3. reste bloquée au-delà du délai canari ;
4. est annulée via `JoinHandle::abort()` ;
5. libère ensuite le verrou administrateur ;
6. prouve que le canonical de l'acquisition annulée n'est pas durable.
Cette preuve exerce un rollback par cancellation réelle, pas une simulation séquentielle.
## 9. Réouverture finale
Après toutes les opérations, le backend est rouvert sur le même réseau. Le test exige :
- health Ready ;
- migration 1 ;
- lecture exacte d'un canonical durable antérieur.
Le cleanup final supprime les cinq tables KSP uniquement parce que leur absence initiale a été prouvée.
## 10. Migrations
Aucune ressource V000/V001 n'est modifiée.
Checksums attendus et recalculés :
```text
V000 d29068b8c13b9dc0cc9ef6aaadd0fa12d41e0fe4c56541a1118c4bfc846a1450
V001 31488cda2f08f3f46c4cdbdbb6c18c243662fada02eac4487040c8735d72cc51
```
V001 reste exactement à 40 ressources.
## 11. Fichiers modifiés
```text
Cargo.toml
crates/ksp-store-postgres-lib/README.md
crates/ksp-store-postgres-lib/USAGE.md
crates/ksp-store-postgres-lib/tests/hardening_completeness.rs
crates/ksp-store-postgres-lib/tests/postgres_raw_transaction_live.rs
docs/plans/024-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION_PLAN.md
docs/validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md
deltas/0.3.3/pre.009.md
```
Aucune suppression de fichier.
## 12. Validation exécutée dans l'environnement de génération
```text
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
KSP workspace Rust rule audit: clean
Markdown table audit: clean
```
Cargo, rustfmt et PostgreSQL réel ne sont pas disponibles dans l'environnement de génération. Le gate opérateur et le live restent donc à exécuter localement.
## 13. Gate opérateur standard
```bash
cargo fmt --all
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/0.3.3
cargo check --workspace
cargo clippy --workspace --all-targets
cargo test -p ksp-store-api
cargo test -p ksp-store-lib
cargo test -p ksp-store-postgres-lib
cargo test -p ksp-config-lib
cargo check -p ksp-store-lib --no-default-features
```
## 14. Gate PostgreSQL live opt-in
Sur une base PostgreSQL dédiée et vide de toute table KSP gérée :
```bash
printf '%s\n' '<URI_POSTGRES_DEDIEE>' | cargo test -p ksp-store-postgres-lib --test postgres_raw_transaction_live -- --ignored --nocapture
```
## 15. Suite si les deux gates sont verts
```text
0.3.3-pre.010 — hardening/completeness
```