# Persistance

> Comment un service LMSP stocke son état, avec une base SQLite intégrée, les tables à conserver, les règles transactionnelles pour les tâches et les événements, la conservation et la reprise au démarrage.

Source: https://madeforagent.com/fr/lmsp/1.0/persistence/
Language: fr
Specification: LMSP 1.0 (draft)
Updated: 2026-11-08

## 11.1 Stockage {#storage}

Un service **DEVRAIT** conserver son état dans une base [SQLite](https://www.sqlite.org/) intégrée. Un jeu de tables suggéré :

| Table | Contenu |
| --- | --- |
| `service_config` | Identité et configuration du service. |
| `clients` | Clients appairés, empreintes des jetons et portées. |
| `models` | Métadonnées des modèles et empreintes de leur contenu. |
| `responses` | Réponses stockées. |
| `tasks` | Tâches asynchrones. |
| `task_events` | Le journal des événements de chaque tâche, avec des numéros de séquence. |
| `idempotency_keys` | Clés d’idempotence, empreintes des requêtes et résultats. |

Les fichiers de modèles **DOIVENT** rester en dehors de la base de données. La base ne contient que des métadonnées et des empreintes de contenu.

Les noms et la structure des tables relèvent de l’implémentation. Ce que les clients peuvent observer, et ce qui doit être interopérable, c’est le comportement décrit dans les deux sections suivantes.

## 11.2 Règles {#rules}

Quel que soit le stockage utilisé, un service :

- **DOIT** persister une tâche avant de renvoyer `202 Accepted`.
- **DOIT** mettre à jour les numéros de séquence des événements et l’état de la tâche dans la même transaction.
- **DOIT** rendre atomique la transition d’annulation, pour éviter la situation de concurrence d’une tâche annulée puis terminée.
- **DEVRAIT** conserver les tâches et les événements terminés pendant une durée de conservation configurable.
- **NE DOIT PAS** supprimer les tâches inachevées lors du nettoyage des journaux.
- **DOIT**, au démarrage, parcourir les tâches `queued`, `loading`, `running` et `cancelling` restantes, et appliquer la politique de redémarrage de chacune ([section 7.5](https://madeforagent.com/fr/lmsp/1.0/tasks.md#restart)).

## 11.3 Reprise au démarrage {#recovery}

Le tableau indique l’état vers lequel une tâche restante est déplacée, selon sa politique `on_restart` :

| État trouvé au démarrage | `fail` | `retry` | `resume` |
| --- | --- | --- | --- |
| `queued` | `failed` | `queued` | `queued` |
| `loading` | `failed` | `queued` | `queued` |
| `running` | `failed` | `queued` | `running`, en reprenant à partir de l’instantané |
| `cancelling` | `cancelled` | `cancelled` | `cancelled` |

Une tâche déplacée vers `failed` reçoit le code d’erreur `server_restarted` et un événement `response.failed`. Une tâche déplacée vers `cancelled` reçoit un événement `response.cancelled`. Le nouvel état et son événement sont écrits dans une seule transaction ([section 11.2](https://madeforagent.com/fr/lmsp/1.0/persistence.md#rules)).