Les flows tournent sans surveillance, donc Hermetry les protège : un flow pris dans une boucle ou qui échoue en boucle se met lui-même en pause, les effets de bord sont limités en débit, et les messages qui n’ont pas pu être exécutés sont conservés comme messages en échec que vous pouvez rejouer. Cette page explique chaque protection et ce que vous faites quand l’une d’elles agit.
Protections des flows
| Protection | Valeur par défaut | Ce qui se passe |
|---|---|---|
| Exécutions par minute | 6 000 exécutions d’un même flow sur une minute glissante | Le flow se met lui-même en pause : une boucle est suspectée |
| Exécutions en échec | 100 exécutions en échec d’affilée | Le flow se met lui-même en pause |
| Exécutions simultanées | 16 exécutions d’un même flow en même temps | Les autres exécutions attendent (1 000 au plus par flow ; au-delà, les plus anciennes sont supprimées) |
| Fan-out | 100 messages envoyés par un bloc pour une même entrée | Les autres messages de ce bloc pour cette entrée sont supprimés |
| Taille des messages | 256 Kio par message | Le message est refusé (msg_too_big) |
| Garde-fou de boucle | 4 sauts d’événements et de Run flow entre flows ; 512 étapes dans une même exécution | La chaîne est coupée |
| Tentatives épuisées | 5 tentatives au maximum pour un appel externe | L’entrée devient un message en échec, sauf si le flow intercepte l’erreur |
| Messages répétés | Un message d’appareil revu dans les 60 secondes | Acquitté sans exécution |
| Trop ancien | Un message qui attend depuis plus de 5 minutes | Non exécuté (les messages d’appareil s’exécutent toujours dans leur root, marqués en retard) |
| Commandes d’appareil par minute | 30 commandes et réglages envoyés depuis les flows vers un même appareil | La commande est refusée (limit) |
| Notifications répétées | La même notification à la même personne dans les 10 minutes | Cette personne est exclue |
Votre offre peut définir d’autres valeurs, dans des limites fixes. Chaque fois qu’une protection agit, elle est comptabilisée : sur la ligne du flow (Limité · protection), dans l’éditeur (« Une protection de flow a agi sur ce flow : … », avec les blocs signalés) et dans la carte d’utilisation (Protections de flows ce mois-ci). Voir Limites des flows.
Un flow mis en pause par lui-même
Un flow en pause ne démarre aucune exécution tant qu’il n’est pas repris. Sa ligne indique la raison :
- « Il s’est mis lui-même en pause : il a tourné plus souvent en une minute que ne le permet cet espace de travail, une boucle est donc suspectée. »
- « Il s’est mis lui-même en pause : trop de ses exécutions ont échoué d’affilée. »
Les responsables de l’automatisation reçoivent l’alerte Flow mis en pause par lui-même. Que faire :
- Ouvrez le flow et regardez Activité > Erreurs ainsi que les Exécutions des dernières minutes.
- Corrigez la cause : cassez la boucle (un flow qui se déclenche lui-même, un déclencheur Status qui surveille un bloc changeant son statut à chaque message), ou corrigez l’appel en échec.
- Déployez, puis Reprendre depuis le menu de la ligne du flow ou la bannière de l’éditeur. Une pause conserve la mémoire du flow et ses messages en attente.
Les roots ne sont jamais mises en pause automatiquement
Un flow root stocke les données de chaque appareil qu’il dessert ; il est donc exclu de la mise en pause automatique et de Exécutions simultanées. Si un root échoue trop souvent, les propriétaires et administrateurs de l’organisation reçoivent l’alerte critique Root non mis en pause (« Ce flow root n’a pas été mis en pause, car il stocke les données de chaque appareil qu’il dessert… »), au plus une fois toutes les 6 heures par flow. Corrigez-le vite : des exécutions en échec d’un root peuvent signifier que des mesures ne sont pas stockées.
L’arrêt d’urgence
L’arrêt d’urgence met en pause tous les flows en cours de l’organisation, sur chaque hôte, d’un coup, roots compris.
- Dans Automatisation, ouvrez le menu de l’en-tête et sélectionnez Arrêter tous les flows.
- Lisez : « Tous les flows en cours de cet espace de travail, sur chaque hôte, sont mis en pause d’un coup : les messages d’appareil, les planifications, les webhooks et les événements ne démarrent aucune exécution tant que vous ne reprenez pas. Les exécutions en cours se terminent. Un flow root est aussi mis en pause, donc les données des appareils ne sont pas stockées entre-temps. »
- Cochez « Je comprends que rien ne s’exécute tant que les flows ne sont pas repris. », saisissez
STOPet confirmez.
Une bannière affiche « Arrêt d’urgence : n flows sont en pause… ». Pour y mettre fin, sélectionnez Reprendre les flows : chaque flow mis en pause par l’arrêt redémarre ; un flow qui s’était mis lui-même en pause reste en pause. Les deux actions sont journalisées.
Ne l’utilisez que lorsque des flows causent des dégâts (envoi de commandes erronées, saturation d’un système partenaire). Les données des appareils ne sont pas stockées tant qu’il est actif.
Messages en échec
Un message que la plateforme n’a pas pu exécuter est conservé comme message en échec (lettre morte). Ouvrez-les depuis le menu de l’en-tête de la liste des flows (Messages en échec, tous les flows d’un hôte) ou dans l’éditeur (Messages en échec, les messages adressés à ce flow).
| Motif | Signification |
|---|---|
| Échecs répétés | Livré plusieurs fois sans aboutir |
| Un appel a échoué à chaque tentative | Un appel externe a épuisé ses tentatives et le flow n’a pas intercepté l’erreur |
| Attente trop longue | Un appel de webhook ou une minuterie nommée a attendu plus longtemps que sa durée de vie (après une panne). « Rejouez-le pour l’exécuter maintenant. » |
| Laissé inachevé par un redéploiement | Son exécution ne s’est pas terminée avant le remplacement de la version sur laquelle elle tournait |
| File d’attente trop longue | Trop de messages de l’organisation attendaient |
| Illisible | L’entrée stockée est endommagée |
| Refusé par l’hôte | L’hôte ne l’a pas accepté |
Chaque ligne affiche Vu la première fois, Motif, Erreur et Tentatives. Voir affiche l’entrée stockée (réservé aux personnes autorisées à déboguer).
- Rejouer remet le message dans la file avec ses identifiants d’origine. « Son exécution a peut-être déjà accompli une partie de son travail : les appels, messages ou écritures qu’elle a faits peuvent se reproduire. » Les blocs qui appellent l’extérieur envoient la même clé d’idempotence, ainsi un destinataire qui déduplique ne voit qu’un appel.
- Supprimer l’efface. Il ne peut plus être rejoué ensuite.
Each host keeps its own failed messages. At most 10,000 are kept by default; beyond that the oldest are trimmed. At 80 % the managers get the alert Failed messages nearly full, at most once every 6 hours.
Un message d’appareil en retard dans un root n’est jamais un message en échec : il est stocké. Une tick de planification en retard est simplement ignorée.
Alertes
Erreurs et alertes (menu de l’en-tête de la liste des flows) affiche les alertes d’automatisation des 6 dernières heures, une ligne par flow déployé avec ses erreurs sur 24 heures, ses messages en échec du jour et son niveau d’enregistrement, les erreurs les plus fréquentes sur 7 jours et les totaux par jour.
La Règle d’alerte décide qui est prévenu et quand :
| Champ | Signification |
|---|---|
| Envoyer les alertes | Activé ou désactivé |
| Erreurs par minute | 1 à 10 000 |
| Minutes consécutives | 1 à 19 |
| Flows | Aucun coché = tous les flows |
| Événements | Aucun coché = tous les types d’alerte |
| Destinataires | Un identifiant d’utilisateur membre par ligne, 100 au maximum. Vide : les personnes autorisées à gérer l’automatisation. Les adresses e-mail ne sont pas acceptées. |
Types d’alerte : Nombreuses erreurs, Appels suspendus (disjoncteur ouvert), Effet de bord limité, Bloc ne démarre pas, Messages en échec presque pleins, Flow mis en pause par lui-même et Root non mis en pause. Root non mis en pause est toujours envoyée, quelle que soit la règle, aux propriétaires et administrateurs ainsi qu’aux destinataires de la règle.
Appels suspendus (disjoncteur)
Un bloc dont les appels externes échouent sans cesse (un point d’accès HTTP hors service) suspend ses appels pendant un certain temps ; ses messages échouent avec circuit_open entre-temps. Les événements du flow affichent Appels suspendus (disjoncteur ouvert), puis Appels repris (disjoncteur fermé). Corrigez le destinataire ; le bloc se rétablit de lui-même.