Trabajos durables y readiness

Sincronizado con el commit 7d452a6 del starter.

Por qué el trabajo se persiste

Una instancia serverless puede congelarse al devolver la respuesta. El trabajo que debe completarse—emails, créditos, borrado de objetos, exportación y eliminación de cuentas—se escribe en jobs, no en promesas sin esperar.

Los tipos actuales cubren emails, invitaciones, créditos de alta, Slack, eliminación de almacenamiento, reservas y ciclo de vida de cuenta.

Encolar

await enqueueJob("welcome_email", { email, name, userUuid }, {
  dedupeKey: `welcome:${userUuid}`,
  subjectUserUuid: userUuid
});

dedupeKey hace idempotente el alta. Los UUID de sujeto permiten cancelar o limpiar trabajos durante un proceso de privacidad. Los handlers también deben ser idempotentes.

Ejecución

GET /api/cron/jobs exige Authorization: Bearer $CRON_SECRET. Vercel lo llama cada cinco minutos; fuera de Vercel debes programarlo.

El runner reclama un trabajo con FOR UPDATE SKIP LOCKED, permite llamadas solapadas, usa leases de cinco minutos, limita cada handler a 20 segundos y el drenaje a 40, reintenta cinco veces por defecto con backoff desde 30 segundos y conserva resultados 14 días. También limpia subidas incompletas y eventos Stripe atascados.

Vida y preparación

/api/health es una sonda barata del proceso. /api/ready verifica configuración, base de datos y migraciones, Redis distribuido y salud de la cola. Un fallo crítico devuelve 503; una cola degradada se informa sin retirar la web del servicio.

Usa health para sondeos frecuentes y ready antes de enviar tráfico a una versión nueva. Alerta por readiness no-200 y por crecimiento de trabajos fallidos. Mantén los payloads compatibles hacia atrás.