Interruption inattendue et reprise automatique

« Que faire si l'exécution n'est pas terminée en même temps » est une question à laquelle le flux de travail au niveau de la production doit répondre. Braidrun propose deux solutions de traitement :

• Par défaut : pause sécurisée — Marquez l'exécution comme INTERROMPUE et attendez de la voir clairement avant de "réessayer" manuellement à partir d'une certaine étape au milieu.
• Facultatif : Continuer automatiquement l'exécution — Après avoir déclaré explicitement « ce workflow peut continuer + quelles étapes sont idempotentes », la plateforme continuera automatiquement à partir du point d'interruption.

Comportement par défaut : pause sécurisée

Lorsqu'une interruption côté plate-forme se produit, la plate-forme :

1. Marquez le statut d'exécution comme INTERRUPTÉ ;
2. Conservez les résultats, les produits et les journaux de toutes les étapes terminées ;
3. Vous recevez une notification sur site (l'email/Slack sera également configuré en fonction de votre notification) ;
4. Lorsque vous accédez à la page des détails de l'exécution, vous pouvez « réessayer depuis l'étape ayant échoué » : la plateforme réutilise les résultats de l'étape précédente.

Cette valeur par défaut est disponible pour tous les workflows et ne nécessite aucune configuration. Convient pour :

• Le workflow contient des effets secondaires externes (envoi d'e-mails/déduction d'argent/modification de la base de données)
• Quand la production ne sait pas encore « s’il est sûr de redémarrer et de continuer à fonctionner »

Facultatif : Continuer automatiquement l'exécution

Si votre flux de travail est un pur pipeline de données (API en lecture seule + génération de rapports), vous pouvez activer la poursuite automatique : après une interruption, la plateforme continuera automatiquement à s'exécuter à partir du point d'interruption, sans que vous ayez à cliquer manuellement.

Opt-in à deux niveaux activé

Pour que la continuation automatique prenne effet, vous devez déclarer les deux couches en YAML :

1. niveau de flux de travail : Déclaration recovery.autoResumeOnRestart: true
2. niveau de marche : Instructions étape par étape pour des rediffusions en toute sécurité idempotent: true

Exemple complet

name: daily-asa-digest
version: "1.0.0"

recovery:
  autoResumeOnRestart: true
  policy: RESUME_FROM_LAST_INCOMPLETE
  maxAutoResumeAttempts: 3

steps:
  - id: fetch_asa_data
    type: sub_workflow
    module: dingyue-module-asa-fetch
    idempotent: true           # 只读拉取，可重跑

  - id: build_excel
    type: sub_workflow
    module: dingyue-module-excel-report
    idempotent: true           # 生成文件到产物目录，可重跑

  - id: notify_team
    type: sub_workflow
    module: dingyue-module-slack-deliver
    # 不写 idempotent —— 默认 false，发消息不可重跑

Trois politiques de récupération

idempotent Comment marquer

L’étalon-or pour déterminer si une étape est idempotente :

« Si la même entrée est exécutée deux fois, y aura-t-il des effets secondaires ? »

Si vous le pouvez (envoyer des messages externes, facturer de l'argent, rédiger des commandes), n'ajoutez pas d'idempotent.

Plusieurs situations qui ne se produiront pas lors de la poursuite automatique

Même si vous configurez la récupération, les exécutions suivantes ne continueront pas à s'exécuter automatiquement :

• La source de déclenchement est un Webhook : la charge utile du Webhook peut être au plus une fois, et la plate-forme ne sait pas si le flux en amont réessayera.
• La source de déclenchement est le planificateur - le planificateur se relancera lors du prochain cycle de cron.
• Actuellement arrêté à manual_approval - en attente d'approbation signifie qu'il est initialement bloqué.
• Le fichier de définition du workflow a été modifié pendant la panne : la plateforme a détecté une incompatibilité de hachage et ne sait pas si la nouvelle version est compatible.

Manuel "Réessayer d'une étape" (disponible à tout moment)

Que le workflow soit configuré avec récupération ou non, la page des détails de l'exécution fournit toujours un bouton « Réessayer après une étape ayant échoué » :

1. Ouvrez une exécution INTERROMPUE / ÉCHEC ;
2. Cliquez sur « Réessayer à partir de cette étape » à côté de l'étape ayant échoué/interrompue ;
3. Le résultat de l’étape COMPLETÉE précédemment sera réutilisé ; cette étape recommence à s'exécuter.

Même si l'étape n'est pas idempotente, vous pouvez la réessayer manuellement - car c'est à ce moment-là que vous, en tant qu'humain, décidez consciemment qu'elle "vaut la peine d'être réexécutée".

Continuer à courir la limite

Empêcher le système de redémarrer la même exécution dans une « boucle infinie » : chaque exécution continuera automatiquement à s'exécuter jusqu'à 3 fois. Si cela échoue toujours, arrêtez-vous et attendez que vous vous en occupiez. Vous pouvez remplacer (1-20) dans recovery.maxAutoResumeAttempts.

Vérification

Les événements d'audit seront enregistrés à chaque fois qu'une poursuite automatique est effectuée :

• execution.auto_resume — Poursuite réussie de l'exécution
• execution.auto_resume.skipped — Selon les règles, vous ne devriez pas continuer à courir, avec raison

L'administrateur peut filtrer et afficher les journaux d'audit selon ces deux types d'événements.

Suggestions pratiques

• Pipeline de données pur (ASA quotidien, résumé RSS) : récupération complète + idempotent, soyez assuré qu'il continuera à fonctionner automatiquement.
• S'il y a des effets secondaires externes (déductions, envoi de messages, passation de commandes) : n'ouvrez pas la reprise automatique. Interrompre la prise de décision humaine.
• Ajoutez manual_approval avant les étapes clés des effets secondaires - l'approbation elle-même est un "point de blocage naturel" pour une exécution discontinue.

Étape suivante

• Surveillance et journalisation de l'exécution — Comment afficher l'exécution dans l'état INTERRUPTÉ
• Meilleures pratiques — Suggestions complètes pour l'annotation/le fractionnement/la modularisation idempotentes