Tâches durables et readiness

Synchronisé avec le commit 2a1a04a du starter.

Utilisez cette page lorsqu’un travail doit aboutir après la fin de la requête navigateur : envoyer un e-mail, attribuer des crédits, supprimer un objet ou traiter une demande de confidentialité. Le starter fournit une file légère sur PostgreSQL ; beaucoup d’équipes peuvent ainsi lancer sans exploiter une file Redis ni un service worker séparé.

Décider comment exécuter et surveiller le travail

• Sur Vercel, conservez le cron de cinq minutes inclus. Ailleurs, appelez le même endpoint authentifié depuis le planificateur de la plateforme.
• Gardez la file PostgreSQL pour un volume modéré et des handlers de moins de 20 secondes. Ne passez à une file dédiée que pour une charge longue ou élevée, en conservant déduplication et idempotence.
• /api/health répond « le processus répond » ; /api/ready répond « cette version peut recevoir du trafic de production ». Ce sont deux signaux distincts.

Prêt pour la production signifie : un job de test est traité, un échec forcé est retenté puis visible, deux crons simultanés ne doublent pas l’effet, et vos alertes détectent readiness en échec et la croissance des jobs failed.

Pourquoi persister le travail

Une instance serverless peut être gelée dès la réponse envoyée. Les actions qui doivent aboutir—emails, crédits, suppression d’objets, export et effacement de compte—sont écrites dans jobs, jamais laissées dans une promesse non attendue.

Les types actuels couvrent emails, invitations, crédits d’inscription, Slack, stockage, réservations et cycle de vie de compte.

Mettre en file

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

dedupeKey rend l’enqueue idempotent. Les UUID de sujet permettent aux workflows de confidentialité d’annuler ou nettoyer le travail. Les handlers doivent eux aussi être idempotents.

Choisir un runner par défaut

La page admin /jobs montre état, tentatives, âge, sujet et erreur sûre sans payload JSON. admin_rw peut rejouer un job idempotent failed ou annuler une notification pending avec une note d’audit ; crédits, stockage, lifecycle et campagnes passent par leur workflow propriétaire.

Runner

GET /api/cron/jobs exige Authorization: Bearer $CRON_SECRET. Vercel l’appelle toutes les cinq minutes ; ailleurs, planifiez cet appel.

Le runner réclame un job via FOR UPDATE SKIP LOCKED, accepte les exécutions concurrentes, utilise un lease de cinq minutes, limite un handler à 20 secondes et un drain à 40, réessaie cinq fois par défaut avec backoff depuis 30 secondes et conserve les résultats 14 jours. Il nettoie aussi les uploads abandonnés et les événements Stripe bloqués.

Vie et préparation

/api/health vérifie seulement le processus. /api/ready contrôle configuration, base et migrations, Redis distribué et état de la file. Une dépendance critique absente renvoie 503 ; une file dégradée est signalée sans retirer le web du service.

Utilisez health pour les sondes fréquentes et ready avant d’envoyer du trafic vers une version. Alertez sur readiness non-200 et sur la croissance des jobs échoués. Gardez les payloads rétrocompatibles.

Avant de planifier cron et d’envoyer du trafic : terminez la Checklist de déploiement et sécurité.