Store PostgreSQL canonique

Baseline active

PostgreSQL reste le backend principal. Le store utilise le schéma courant du profil, généralement public, et ne qualifie pas les tables par un schéma applicatif explicite.

La baseline active contient :

kb_sol_raw_transactions
kb_sol_obs_transaction_observations
kb_sol_core_transactions
kb_sol_core_account_keys
kb_sol_core_instructions
kb_sol_core_inner_instructions
kb_sol_core_logs
kb_sol_core_balance_changes
kb_sol_ops_processing_ledger
kb_sol_decode_events
kb_sol_decode_coverage_declarations
kb_sol_decode_coverage_observations
kb_sol_mat_events

Initialisation

Le projet utilise encore des DDL idempotents gérés par kb_store_pg. _sqlx_migrations n’est pas requis pour démarrer l’application.

Les fichiers SQL actifs sont conservés comme représentation lisible de la baseline :

0001_canonical_transaction_store.sql
0002_core_store.sql
0003_processing_ledger.sql
0004_decode_materialization_store.sql

Au démarrage Tauri, initialize_store_schema() applique une seule fois, dans l’ordre, les DDL raw, core puis decode/mat. Les connexions ouvertes ensuite par les commandes de démo désactivent auto_initialize_schema et ne relancent plus les migrations. Les méthodes spécialisées restent disponibles pour les tests et outils qui demandent explicitement l’initialisation d’un sous-ensemble dépendant.

Extraction canonique vers core

CoreExtractionStore sélectionne les lignes raw, vérifie le ledger puis persiste un CoreExtractionBundle dans une transaction PostgreSQL unique.

Le mode normal skippe la combinaison déjà réussie :

processor version + signature + canonical hash

Le replay forcé remplace uniquement le graphe de la signature ciblée. Les autres signatures ne sont pas modifiées.

Tests PostgreSQL

Les tests qui utilisent KB_POSTGRES_TEST_URL doivent être lancés sur une base dédiée ou suivis d’un nettoyage explicite.

Depuis 0.4.1-pre.021, les tests optionnels qui partagent une base PostgreSQL réelle acquièrent un verrou process-local test-only. Ce verrou évite les interblocages intermittents entre campagnes de tests parallèles sans changer le code runtime ni le schéma SQL.

Les tests optionnels couvrent notamment le rollback atomique core/decode, la persistance réelle du ledger et la sémantique exacte des déclarations de couverture. optional_postgres_core_extraction_rolls_back_partial_graph_from_env :

insère une ligne raw isolée ;
tente de persister un bundle contenant deux account keys avec le même index ;
attend une violation de l’index unique après le début de la transaction ;
vérifie qu’aucune transaction core, account key ou entrée ledger n’a été conservée et que le raw reste received ;
rejoue un bundle corrigé ;
vérifie le passage à core_extracted et le ledger succeeded ;
nettoie ses lignes de test.

Commande de clôture :

KB_POSTGRES_TEST_URL='postgres://solana:solana@localhost:5432/solana_test' \
  cargo test -p kb_store_pg -- --nocapture

Les contrôles réels déjà effectués sur la base principale ont confirmé :

70 transactions raw et core ;
70 entrées ledger succeeded ;
84 tentatives après un force replay de 14 signatures ;
aucune duplication ni ligne fille orpheline ;
cardinalité core inchangée après remplacement forcé.

Couverture et skip decode

persist_decode_coverage_declarations() synchronise le snapshot déclaré d’un processor/version et retourne des compteurs exacts : insertion réelle, modification/suppression du snapshot ou déclaration inchangée.

Le test PostgreSQL optional_postgres_same_version_and_hash_is_current_from_env persiste un résultat unsupported puis vérifie que le même stage, processor, version, input key et input hash est reconnu comme courant par le ledger.

3.9 KiB Raw Permalink Blame History Unescape Escape