Skip to main content
Utilisez la surface de cycle de vie lorsque les mémoires reflètent des enregistrements dont votre base de données est propriétaire — lignes de CRM, champs de profil, tickets. Contrairement au save en append-only, ces mémoires ont une identité durable et un historique de versions, de sorte que les corrections et suppressions issues de la source de vérité s’appliquent exactement une fois, dans l’ordre, quelle que soit la qualité de la livraison.

Le modèle d’identité

Une mémoire appartenant à une source est identifiée par (endUserId, source, externalId). version doit augmenter chaque fois que l’enregistrement source change.

Garanties de livraison

Les mutations sont synchrones, et les règles sont simples :
  • Réessayer la même version + payload renvoie le même reçu durable. Renvoyer après un crash est sûr — c’est ça, la stratégie de reprise après crash.
  • Un payload différent pour une version existante renvoie 409. Les versions sont immuables.
  • Une version plus ancienne retardée renvoie 409 et n’écrase jamais un contenu plus récent ni ne ressuscite une mémoire supprimée.
Les suppressions suivent le même versioning :
La suppression est durable : les retries convergent vers le reçu original, et les upserts retardés avec des versions inférieures ne peuvent pas recréer la mémoire.

Amorçage avec un outbox

Miroir en masse d’enregistrements existants via lifecycleBatch — jusqu’à 100 éléments et 1 Mio de contenu agrégé par appel. Il n’y a pas de tâche d’import côté serveur ; un outbox côté client qui renvoie après un crash constitue toute la stratégie de reprise :
result.success signifie seulement « le lot a été traité » — vérifiez toujours les résultats par élément. Marquez une ligne comme terminée sur success ou stale_source_version (les deux signifient que la version est déjà durable), puis envoyez le lot suivant.

Relecture

GET /api/v1/memories/{externalId} renvoie la mémoire et son dernier reçu appliqué — utile pour vérifier la convergence après une migration.