Retención de jobs

Cada ejecución deja filas: el job, sus pasos, y el payload que la disparó. Sin una política, esas tablas crecen para siempre.

Ventanas por defecto#

Se miden desde que el job terminó, no desde que empezó.

Los fallos se guardan más tiempo que los éxitos a propósito: una ejecución exitosa no es evidencia de nada que alguien pregunte después, y una que quedó en la cola de muertos es justo la fila que se abre en un post-mortem.

Qué nunca se borra#

Un job que no terminó no es elegible, sin importar su edad. Eso incluye:

• Queued y Running — está trabajando.
• WaitingHuman — espera una aprobación o un formulario.
• WaitingTimer — espera un delay.

Un job parqueado en un temporizador de seis meses está esperando, no terminado. Borrarlo tiraría trabajo que el cliente todavía espera que ocurra.

Qué se borra junto con el job#

Los pasos del job, sus esperas de temporizador, sus formularios y sus aprobaciones.

Las decisiones de aprobación no se pierden: quién aprobó qué ya está en el registro de auditoría, que la retención nunca toca. Lo que desaparece es el registro operativo de una ejecución vieja, no el registro de cumplimiento.

Purgar a mano#

Antes de borrar, mirá el alcance:

GET /v1/jobs/retention

{
  "enabled": true,
  "windows": [
    { "status": "Completed", "days": 30, "purgeableNow": 1284 },
    { "status": "Failed", "days": 90, "purgeableNow": 12 }
  ],
  "totalPurgeableNow": 1296
}

Y después:

POST /v1/jobs/purge

{ "statuses": ["Completed"], "olderThanDays": 7 }

Ambos campos son opcionales: sin statuses aplica a todos los estados terminales, y sin olderThanDays usa las ventanas configuradas.

Solo Owner y Admin pueden purgar. Un Operator trabaja la cola de fallidos —reintenta, descarta, edita payloads— pero no borra la evidencia de ese trabajo.

El barrido automático#

Corre cada hora, borra por lotes y no se ejecuta al arrancar el proceso: un despliegue que se reinicia en bucle martillaría el borrado más grande del sistema sin ganar nada.

Cada barrido que borra algo deja una fila job.purged en la auditoría, atribuida al servicio. Un purgado manual queda atribuido a la persona.

Los payloads#

Los cuerpos crudos que dispararon cada ejecución viven en MongoDB con vencimiento propio a los 30 días, independiente de todo lo anterior.

O sea que un job Failed de 60 días todavía existe como fila, pero su payload original ya no. Es esperable: para diagnosticar suele alcanzar con el error y las entradas y salidas de cada nodo, que sí están.