0.3.16-pre.009
This commit is contained in:
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user