Files
khadhroony-solana-project/deltas/0.3.3/pre.009-fix.003.md

106 lines
3.4 KiB
Markdown

<!-- file: deltas/0.3.3/pre.009-fix.003.md -->
<!-- version: 1 -->
# Delta `0.3.3-pre.009-fix.003` — ressource V001 post-apply identifiable sans fuite
## 1. Base et constat
Base opérateur :
```text
0.3.3-pre.9.fix.2
```
Le gate standard fourni le 2026-08-30 est entièrement propre : audits Rust/Markdown, `cargo check --workspace`, Clippy all-targets, tests Store/API/backend/Config et `--no-default-features` passent.
Le live PostgreSQL réel atteint PostgreSQL 17 puis échoue pendant `PostgresBackend::open` avec la phase :
```text
schema_resource_post_apply
```
Cette phase prouve qu'une ressource V001 a bien été exécutée mais que l'introspection immédiate la classe ensuite `Missing` ou `Incompatible`. Elle ne permet toutefois pas encore de savoir quelle ressource parmi les 40 est concernée.
## 2. Version
```text
workspace.package.version = 0.3.3-pre.9.fix.3
```
## 3. Diagnostic post-apply exact et secret-safe
Dans `ensure_resource`, le seul chemin `post_apply_incompatible` conserve `MigrationMismatch` mais utilise désormais :
```rust
resource.id
```
comme `PostgresBackendError::phase()`.
`SchemaResource::id` est une chaîne `&'static str` embarquée dans le binaire et contrôlée par KSP, par exemple :
```text
tables/002_ksp_raw_transactions.sql
constraints/006_ck_ksp_raw_transactions_slot.sql
indexes/001_ix_ksp_raw_transactions_slot_signature.sql
```
Elle ne contient aucune URI, valeur de configuration, donnée utilisateur, SQLSTATE, bind, texte serveur ou payload. Le prochain live peut donc identifier exactement la ressource fautive sans affaiblir la redaction.
Les autres phases de migration restent inchangées.
## 4. Pourquoi aucune correction SQL n'est appliquée ici
Le live ne fournit encore que la classification `schema_resource_post_apply`. V000 est déjà acquis sur PostgreSQL 17 et aucune incompatibilité évidente ne justifie de modifier à l'aveugle une ressource V001 ou son comparateur de catalogue.
`fix.003` est donc volontairement diagnostique : la prochaine exécution doit donner l'identifiant exact, puis le correctif suivant pourra cibler le contrat d'introspection ou la ressource concernée avec preuve.
## 5. Invariants
Aucun changement de :
- fichiers SQL V000/V001 ;
- ordre ou nombre des 40 ressources V001 ;
- checksums migrations ;
- Store API / façade ;
- RawTransaction reads/writes/pagination/rétention ;
- cursor ;
- Config ;
- scope `RawAccountState`.
## 6. Fichiers modifiés
```text
Cargo.toml
crates/ksp-store-postgres-lib/src/migration.rs
docs/validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md
deltas/0.3.3/pre.009-fix.003.md
```
Aucune suppression.
## 7. Gate opérateur attendu
```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
```
Puis :
```bash
read -rsp "Dedicated PostgreSQL URI: " KSP_PG_TEST_URI; echo
printf '%s\n' "$KSP_PG_TEST_URI" | cargo test -p ksp-store-postgres-lib --test postgres_raw_transaction_live -- --ignored --nocapture --test-threads=1
unset KSP_PG_TEST_URI
```
Si le post-apply échoue encore, le message doit maintenant exposer uniquement l'identifiant statique de la ressource V001 concernée.