# Persistencia

> Cómo un servicio LMSP almacena su estado, con una base de datos SQLite integrada, las tablas que conservar, las reglas transaccionales para tareas y eventos, la retención y la recuperación al arrancar.

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

## 11.1 Almacenamiento {#storage}

Un servicio **DEBERÍA** guardar su estado en una base de datos [SQLite](https://www.sqlite.org/) integrada. Un conjunto de tablas sugerido:

| Tabla | Contenido |
| --- | --- |
| `service_config` | Identidad y configuración del servicio. |
| `clients` | Clientes emparejados, hashes de tokens y ámbitos. |
| `models` | Metadatos de los modelos y resúmenes criptográficos de su contenido. |
| `responses` | Respuestas almacenadas. |
| `tasks` | Tareas asíncronas. |
| `task_events` | El registro de eventos de cada tarea, con números de secuencia. |
| `idempotency_keys` | Claves de idempotencia, resúmenes de solicitudes y resultados. |

Los archivos de modelo **DEBEN** quedar fuera de la base de datos. La base de datos contiene solo metadatos y resúmenes criptográficos del contenido.

Los nombres y la disposición de las tablas son una decisión de implementación. Lo que los clientes pueden observar, y lo que tiene que ser interoperable, es el comportamiento descrito en las dos secciones siguientes.

## 11.2 Reglas {#rules}

Sea cual sea el almacenamiento que use un servicio, este:

- **DEBE** persistir una tarea antes de devolver `202 Accepted`.
- **DEBE** actualizar los números de secuencia de los eventos y el estado de la tarea en la misma transacción.
- **DEBE** hacer atómica la transición de cancelación, para evitar la condición de carrera de una tarea que se cancela y luego se completa.
- **DEBERÍA** conservar las tareas y los eventos terminados durante un período de retención configurable.
- **NO DEBE** eliminar tareas sin terminar durante la limpieza de registros.
- **DEBE**, al arrancar, examinar las tareas `queued`, `loading`, `running` y `cancelling` que hayan quedado, y aplicar la política de reinicio de cada una ([sección 7.5](https://madeforagent.com/es/lmsp/1.0/tasks.md#restart)).

## 11.3 Recuperación al arrancar {#recovery}

La tabla muestra el estado al que pasa una tarea que quedó pendiente, según su política `on_restart`:

| Estado encontrado al arrancar | `fail` | `retry` | `resume` |
| --- | --- | --- | --- |
| `queued` | `failed` | `queued` | `queued` |
| `loading` | `failed` | `queued` | `queued` |
| `running` | `failed` | `queued` | `running`, continuando desde la instantánea |
| `cancelling` | `cancelled` | `cancelled` | `cancelled` |

Una tarea que pasa a `failed` recibe el código de error `server_restarted` y un evento `response.failed`. Una tarea que pasa a `cancelled` recibe un evento `response.cancelled`. El nuevo estado y su evento se escriben en una sola transacción ([sección 11.2](https://madeforagent.com/es/lmsp/1.0/persistence.md#rules)).