Configuration locale

Ce dossier contient les exemples et le schéma de configuration JSON.

Règles

Le fichier versionné doit rester sans secret.
Les placeholders de clés restent directement dans les URLs.
Le champ active_profile sélectionne un seul profil actif.
Un profil actif doit être présent et unique.
Les profils non actifs peuvent rester dans le fichier pour les tests devnet, mainnet lecture seule, backfill ou future production.
Le contrat courant couvre HTTP JSON-RPC Solana et WebSocket JSON-RPC générique.
Helius transactionSubscribe et Yellowstone gRPC seront ajoutés plus tard dans kb_onchain_transport, avec évolution explicite du schéma quand les transports seront réellement utilisés.
Les IDLs restent des artefacts de développement et ne font pas partie de la configuration runtime.

Fichiers

example.config.json : exemple complet avec profils local_devnet, mainnet_research et mainnet.
schema.config.json : JSON Schema de validation du fichier de configuration.

Variables d’environnement de l’exemple

example.config.json conserve la topologie des profils et référence les valeurs locales avec des placeholders :

HELIUS_API_KEY
KB_POSTGRES_MAINNET_URL
KB_POSTGRES_DEVNET_URL

KB_POSTGRES_TEST_URL n’est pas utilisé par un profil runtime : il reste réservé aux tests d’intégration PostgreSQL. Le profil local_devnet utilise KB_POSTGRES_DEVNET_URL; les profils mainnet_research et mainnet utilisent KB_POSTGRES_MAINNET_URL. Les trois bases doivent être distinctes.

Le fichier réel .env reste local et ignoré par Git. .env.example est le seul modèle dotenv versionné.

Phase `0.3.x`

0.3.x utilise les endpoints HTTP des profils de recherche existants pour :

getSignaturesForAddress
getTransaction
getSignatureStatuses

Aucun profil Helius payant ou Yellowstone n’est activé à ce stade.

Les sources futures devront déclarer séparément :

provider ;
protocole ;
rôle ;
limites de streams et filtres ;
authentification ;
région éventuelle.

Évolution du schéma

schema.config.json est le contrat de validation runtime. Il évolue seulement lorsqu’un champ est réellement utilisé par l’exécution.

Logging de développement

L’exemple configure, pour chacun des trois profils, quatre fichiers globaux puis trois fichiers dédiés par crate opérationnelle utilisant tracing : debug.log, info.log et error.jsonl.

Les matérialisateurs natifs consolidés rejoignent la console et disposent de leurs routes propres sous :

logs/<profil>/kb-lib/materializer/admin/
logs/<profil>/kb-lib/materializer/compliance/audit/
logs/<profil>/kb-lib/materializer/lifecycle/
logs/<profil>/kb-lib/materializer/risk/
logs/<profil>/kb-lib/materializer/staking/
logs/<profil>/kb-lib/materializer/token/accounts/
logs/<profil>/kb-lib/materializer/transaction/annotations/

Le test de configuration découvre dynamiquement toutes les crates déclarant tracing.workspace = true et vérifie leurs trois routes dans chaque profil. Les logs ne doivent contenir ni secret, ni DSN non masqué, ni payload Config ou bytecode complet.

3.2 KiB Raw Blame History Unescape Escape