kazzle.config.ts. Un composant peut avoir autant de déclencheurs que nécessaire.
La structure
processModedéfinit le cycle de vie — serveur long-running, ou exécution unique par déclencheur.triggers[]liste les événements qui doivent déclencher ce composant.
processMode
| Mode | Ce qui s’exécute | Quand l’utiliser |
|---|---|---|
persistent (par défaut) | Un serveur HTTP long-running. Les déclencheurs lui sont POSTés. | Le composant sert déjà HTTP, ou maintient un état en mémoire (files d’attente, websockets, caches). |
triggered | Le script d’entrée est lancé par déclencheur et se termine. | Tâches de fond pures — nettoyage nocturne, gestionnaire webhook Stripe unique, etc. Pas de serveurs inactifs. |
Déclencheurs
Chaque déclencheur a unname (unique dans le composant), un kind, et — selon le mode — un schedule et/ou un path.
| Champ | Quand requis | Notes |
|---|---|---|
name | toujours | Utilisé comme segment d’URL webhook et dans les logs. Kebab-case. |
kind | toujours | 'schedule' ou 'webhook'. |
schedule | quand kind: 'schedule' | Expression cron à 5 champs. La résolution à la minute est le minimum. |
path | quand processMode: 'persistent' | Route HTTP sur votre serveur où le déclencheur arrive. |
Mode persistent — HTTP vers le serveur
Quand un déclencheur se déclenche pour un composant persistent, Kazzle POST vers votre serveur aupath déclaré. La requête contient :
| En-tête | Ce qu’il vous dit |
|---|---|
Authorization: Bearer ${KAZZLE_TRIGGER_SECRET} | Validez ceci. Rejetez les appels qui ne correspondent pas. |
x-kazzle-trigger-name | Le name du déclencheur du manifeste. |
x-kazzle-trigger-run-id | ID opaque pour la corrélation des logs. |
x-kazzle-triggered-by | cron | webhook | manual. |
Mode triggered — exécution unique par déclencheur
Quand un déclencheur se déclenche pour un composanttriggered, Kazzle lance le script d’entrée à neuf et attend sa fermeture. Il n’y a pas de path ; le script apprend quel déclencheur s’est déclenché via des variables d’environnement.
| Variable d’env | Valeur |
|---|---|
TRIGGER_NAME | Le name du déclencheur du manifeste. |
TRIGGERED_BY | cron | webhook | manual. |
RUN_ID | ID opaque pour la corrélation des logs. |
WEBHOOK_PAYLOAD | Corps JSON (déclencheurs webhook uniquement). |
URLs des webhooks
triggerName doit correspondre à une entrée kind: 'webhook' dans le triggers[] de ce composant. Les noms de déclencheurs inconnus retournent 404.
Résolution du calendrier
Les expressions cron sont à 5 champs (minute, heure, jour du mois, mois, jour de la semaine) et la résolution à la minute est le minimum. Les calendriers sub-minute sont rejetés lors de la validation du manifeste.Comment les exécutions sont enregistrées
Chaque déclenchement écrit une ligneprocess_runs avec le trigger_name, triggered_by, run_id, et le statut de sortie de l’exécution. Vous pouvez les interroger depuis votre propre code ou les inspecter dans la vue des exécutions de l’app.
Manque de crédits
Une exécution échouée est enregistrée et loggée, mais le calendrier continue à s’exécuter selon son cadence normal — une exécution défaillante ne désactive jamais le déclencheur. La seule chose qui arrête une exécution est les crédits : chaque déclenchement est vérifié par rapport au solde de l’espace, et tant que l’espace n’a pas de crédits (ou n’a pas de facturation configurée), les exécutions sont ignorées avec un402. C’est auto-récupérable — le calendrier reste armé et le prochain déclenchement après recharge s’exécute normalement, sans reprise manuelle.
Ajouter des automations plus tard
Une app simple peut commencer sans déclencheurs et en gagner plus tard — ajouter un résumé quotidien, connecter Stripe, exécuter un nettoyage. Le cycle de vie du composant (processMode) et les déclencheurs (triggers[]) sont indépendants, vous pouvez donc les modifier sans réécrire le reste de l’app.