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

v0.0.3-pre.007

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-14 12:14:00 +02:00
parent 2cb9f809b7
commit 3b5d1a8f7a
13 changed files with 1447 additions and 121 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
docs/IDEAS.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/IDEAS.md -->
<!-- version: 10 -->
<!-- version: 11 -->
# Idées à explorer
@@ -228,20 +228,50 @@ Le journal D3 doit accepter les outputs de materializers officiels ou externes s
### Backlog et checkpoints
**Status :** À explorer en `pre.007`
**Status :** Transférée vers une décision/règle
Les notifications restent des wake-ups. Définir comment chaque worker/job interroge le Store pour retrouver les inputs non traités par une version donnée, avec pagination, batching, reprise et concurrence.
Les processing outcomes par processor/version/capability constituent la vérité du backlog. Les cursors sont des optimisations et les jobs historiques conservent en plus leurs checkpoints de source.
### Jobs de replay
**Status :** À explorer en `pre.007`
**Status :** Transférée vers une décision/règle
Prévoir des jobs séparés pour D1 -> D2, D2 -> D3 et D3 -> D4 plutôt qu'un replay monolithique obligatoire.
Les noms définitifs ne sont pas encore retenus.
Trois jobs distincts sont retenus : `ksp-job-replay-core`, `ksp-job-replay-generic-materialization` et `ksp-job-replay-domain-projection`. Ils réutilisent les pipelines spécialisés correspondants.
### Notification backend de référence
**Status :** À explorer en `pre.007`
**Status :** Transférée vers une décision/règle
PostgreSQL LISTEN/NOTIFY est un candidat naturel pour la première implémentation de signal de réveil, mais le contrat doit rester indépendant du mécanisme et le Store reste la source de vérité.
PostgreSQL LISTEN/NOTIFY est retenu comme mécanisme initial de référence de wake-up, combiné à un periodic polling du backlog. Le Store reste la source de vérité.
## Workers / jobs — questions d'implémentation restantes
### Claim/lease PostgreSQL
**Status :** À explorer avec la première implémentation Store/worker
Définir le schéma SQL, la durée/renouvellement de lease et la technique PostgreSQL exacte permettant plusieurs instances concurrentes sans bloquer définitivement un input après crash.
### Processing outcomes
**Status :** À explorer avec D2/D3/D4 réels
Fixer les noms/types exacts et distinguer Produced, NoOutput, NotApplicable, Unsupported et failure déterministe sans transformer des situations normales en erreurs.
### Contexte stateful des projectors
**Status :** À explorer avec la première projection nécessitant un état existant
Le Store est interrogé par le pipeline/worker puis le contexte est injecté au `DomainProjector`. Définir comment le projector décrit les données de contexte nécessaires sans dépendre du backend.
### Job pause/resume
**Status :** À explorer avec `ksp-job-api`
Checkpoint/restart est nécessaire pour backfill/replay. Déterminer si pause/resume doit être une capability générique ou rester spécifique aux jobs qui la supportent.
### Télémétrie opérationnelle
**Status :** À explorer
Backlog count, oldest pending age, processing rate et failure rate doivent être observables. Décider plus tard si health/status + logging suffisent ou si une API/metrics exporter dédiée devient nécessaire.