Les recettes ／ tache-sql-pure
Une tâche SQL qui n’a pas de code
pg_cron dit « succeeded » alors que l’appel n’est jamais parti.
Ceux dont les tâches planifiées vivent dans la base.
Le piège que cette recette évite
C’est une panne réelle, racontée sur le forum : `pg_cron` enregistre « succeeded » dès que la COMMANDE SQL s’est exécutée. Si cette commande est un appel HTTP et qu’il échoue, le statut reste « succeeded ». La journalisation de la base ment, sans mentir : elle répond à une autre question que celle qu’on lui pose.
1 tâche
Tâche SQL planifiée
Le battement vient de la tâche SQL elle-même, avec le nombre de lignes traitées. Le silence se voit ici, pas dans le journal de la base — qui déclarera « succeeded » jusqu’au bout.
attend un battement ·
*/15 * * * *· alerte si le volume tombe à zéro
La poser
Rien à remplir : ces tâches attendent un battement de ton côté, LeTock n’appelle rien.
POST /api/v1/recettes/tache-sql-pure/poser
Authorization: Bearer <ta clé>
{}L’appel est rejouable : deux fois la même recette rend les mêmes tâches, sans doublon. Un agent qui n’a pas reçu la réponse peut donc recommencer sans rien casser.