0.3.16-pre.009

This commit is contained in:
2026-09-22 08:59:09 +02:00
parent f2227dce21
commit 40add02ac2
16 changed files with 498 additions and 105 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: crates/ksp-job-backfill-lib/README.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# ksp-job-backfill-lib
@@ -56,7 +56,7 @@ ksp-job-backfill-lib
-X-> backend imposé par le job
```
Le chemin d'écriture est l'acquisition atomique `RawTransaction + RawTransactionObservation` en mode normal. La crate distingue insertion, déjà présent, tombstone purgé, observation nouvelle/existante, missing et conflit. Un conflit de contenu n'est jamais converti en succès idempotent.
Le chemin d'écriture est l'acquisition atomique `RawTransaction + RawTransactionObservation` en mode normal. La crate distingue insertion, déjà présent, tombstone purgé, observation nouvelle/existante, missing et conflit. Depuis `0.3.16`, un outcome Store `QuarantinedConflict` est projeté en `BackfillEntityPersistence::Conflict` tout en conservant l'outcome réel de l'observation (`Inserted` ou `AlreadyPresent`) ; il n'est jamais aplati en simple succès idempotent. Le code d'erreur legacy `ERROR_CODE_RAW_CONFLICT` reste pris en charge pour compatibilité.
## Concurrence et checkpoint
@@ -112,7 +112,7 @@ La crate ne possède pas :
- Worker API / worker live ;
- retry, pacing ou sélection d'endpoint Transport ;
- backend Store concret ;
- decoding Program ou matérialisation CORE/DECODE/SPECIALIZED ;
- decoding Program ou matérialisation STRUCTURAL/DECODED/DOMAIN ;
- table dédiée de checkpoint ;
- control plane Job générique.

View File

@@ -1,5 +1,5 @@
<!-- file: crates/ksp-job-backfill-lib/USAGE.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Utilisation de ksp-job-backfill-lib
@@ -191,7 +191,7 @@ entity: Inserted | AlreadyPresent | SkippedPurged | Conflict
observation: Inserted | AlreadyPresent | NotRecorded | NotApplicable
```
`Missing` ne provoque aucune écriture Store. Un conflit de contenu reste observable comme conflit et ne doit pas être traité comme une relance idempotente réussie.
`Missing` ne provoque aucune écriture Store. Un `QuarantinedConflict` durable reste observable comme `Conflict`, mais l'outcome de l'observation Store est conservé : une réobservation peut donc produire `Conflict + AlreadyPresent`. Ce cas ne doit jamais être aplati en simple relance idempotente réussie. Un backend legacy qui renvoie encore le code Store de conflit est également projeté comme conflit de compatibilité.
## Frontières à respecter
@@ -203,4 +203,4 @@ Le caller ne doit pas :
- utiliser provider/endpoint comme identité transactionnelle ;
- inventer une provenance pour `getTransaction = null` ;
- interpréter un checkpoint caller-owned comme une garantie de persistence crash-safe automatique ;
- utiliser le job RAW comme decoder Program ou processor CORE.
- utiliser le job RAW comme decoder Program ou processor STRUCTURAL.