Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.3.3-pre.009-fix.003

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-30 14:56:51 +02:00
parent 8da04717b6
commit 5e2f959c01
4 changed files with 114 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/020-V0_3_3_STORE_POSTGRES_RAW_TRANSACTION.md -->
<!-- version: 16 -->
<!-- version: 17 -->
# Validation `0.3.3` — Store/PostgreSQL RawTransaction vertical slice
@@ -643,8 +643,10 @@ cap 500/1000 dans Store pagination
- gate opérateur `pre.009-fix.001` du 2026-08-30 : `cargo check --workspace`, tests API/façade/backend/Config et `--no-default-features` passent, mais Clippy bloque le test live sur trois closures sans `return` explicite et remonte deux guards redondants ;
- live réel `pre.009-fix.001` avec URI dédiée valide : PostgreSQL 17 est joint, puis l'ouverture backend échoue encore sous l'étiquette trop générique `backend_open` ; aucune conclusion sur le schéma n'est tirée sans phase sûre plus précise ;
- `pre.009-fix.002` corrige uniquement les cinq diagnostics Clippy du test et propage `PostgresBackendError::phase()` vers `LiveFailure` lors de `open_backend`, sans rendre le texte PostgreSQL, l'URI, SQLSTATE ou bind ;
- gate Cargo standard de `pre.009-fix.002` : À EXÉCUTER côté opérateur ;
- test PostgreSQL réel `--ignored` : À RELANCER ; si l'ouverture échoue, la phase statique backend doit désormais identifier l'étape exacte.
- gate Cargo standard de `pre.009-fix.002` du 2026-08-30 : PASS complet, audits/check/Clippy/tests/no-default-features propres ;
- live PostgreSQL réel `pre.009-fix.002` : PostgreSQL 17 joint puis FAIL à `schema_resource_post_apply`, ce qui localise le défaut dans la relecture d'une ressource V001 juste après son application ;
- `pre.009-fix.003` conserve la redaction mais remplace, uniquement pour ce cas post-apply, la phase agrégée par `resource.id`, identifiant embarqué statique et non sensible ; le prochain live doit donc nommer exactement `tables/...`, `constraints/...` ou `indexes/...` ;
- aucune logique SQL/migration n'est modifiée par `fix.003` : il s'agit d'une instrumentation diagnostique sûre avant correction de la ressource réellement fautive.
### `pre.010`