Error handling during workflow integration - CloudFlow - Centre de documentation Alibaba Cloud

Les workflows CloudFlow peuvent rencontrer des erreurs attendues ou inattendues lors de leur exécution. La gestion des erreurs permet une récupération gracieuse en relançant l'état ayant échoué ou en basculant vers un autre état.

Deux mécanismes fonctionnent conjointement :

Retry : réexécute automatiquement l'état ayant échoué. Utilisez cette option pour les erreurs temporaires, telles que la limitation de débit (throttling) ou les problèmes réseau passagers.
Catch : fait basculer le workflow vers un état désigné lorsqu'une erreur persiste après épuisement de toutes les tentatives de relance.

CloudFlow évalue toujours Retry en premier. Il n'évalue Catch qu'après l'échec de toutes les tentatives de relance.

États pris en charge

Ajoutez les champs Retry et Catch aux types d'états suivants :

Retry

Le champ Retry accepte un tableau de règles de relance. Chaque règle spécifie les erreurs à cibler et la méthode de relance à appliquer.

Paramètre	Type	Obligatoire	Description	Exemple
`Errors`	[]string	Oui	Types d'erreurs à cibler. Consultez la section Types d'erreurs.	`["MyCustomError", "FnF.ALL"]`
`Description`	string	Oui	Libellé de cette règle de relance.	`Retry policy #1`
`MaxAttempts`	int	Oui	Nombre maximal de tentatives de relance.	`3`
`IntervalSeconds`	int	Oui	Intervalle initial entre les relances, en secondes. Maximum : 86 400 (24 heures).	`10`
`BackoffRate`	float	Non	Multiplicateur appliqué à `IntervalSeconds` après chaque tentative. Si ce paramètre est omis, l'intervalle reste constant.	`2`
`MaxBackoffSeconds`	int	Non	Limite supérieure de l'intervalle de relance calculé, en secondes. Maximum : 86 400 (24 heures).	`30`

Remarque

Si plusieurs règles de relance correspondent au même type d'erreur, CloudFlow utilise uniquement la première règle correspondante. Placez les types d'erreurs plus spécifiques avant FnF.ALL afin qu'ils soient évalués en premier.

Catch

Le champ Catch accepte un tableau de règles de capture. Lorsqu'une erreur persiste après toutes les relances, CloudFlow évalue les règles de capture dans l'ordre et bascule vers l'état Next de la première règle correspondante.

Paramètre	Type	Obligatoire	Description	Exemple
`Errors`	[]string	Oui	Types d'erreurs à cibler. Consultez la section Types d'erreurs.	`["MyCustomException1", "FnF.ALL"]`
`Description`	string	Oui	Libellé de cette règle de capture.	`Error catch rule #1`
`OutputConstructor`	map[string]any	Non	Construit une sortie personnalisée à transmettre en tant qu'entrée à l'état `Next`. Consultez la section State OutputConstructor.	Voir les exemples ci-dessous.
`Next`	string	Oui	État vers lequel basculer lorsque l'erreur est capturée.	`my-next-state`

OutputConstructor

Lorsqu'une erreur se produit, l'état ayant échoué ne génère aucune sortie. Sans OutputConstructor, l'état suivant ne reçoit aucune entrée et le workflow ne peut pas se poursuivre correctement. Utilisez OutputConstructor pour créer une sortie structurée que l'état Next pourra exploiter.

Remarque

Si plusieurs règles de capture correspondent au même type d'erreur, CloudFlow utilise uniquement la première règle correspondante.

Types d'erreurs

Erreurs CloudFlow

Ces erreurs proviennent du moteur CloudFlow lui-même.

Type d'erreur	Description
`FnF.TaskTimeout`	Une étape unique du workflow a expiré.
`FnF.Timeout`	L'exécution globale d'un workflow a expiré.
`FnF.ALL`	Caractère générique qui capture toutes les erreurs de CloudFlow. Placez-le en dernière position dans votre tableau `Retry` ou `Catch` afin que les règles plus spécifiques soient évaluées en premier.

Erreurs Function Compute

Ces erreurs surviennent lorsque CloudFlow appelle Function Compute. Pour les types d'erreurs liés à d'autres intégrations de services, consultez la documentation correspondante du service.

Type d'erreur	Description
`FC.ResourceThrottled`	Fonctions limitées en raison d'une concurrence élevée. Toutes les fonctions sont soumises à une limite de concurrence totale. CloudFlow appelle Function Compute de manière synchrone lors de l'exécution des états Task. La valeur de concurrence totale est la somme de la valeur de concurrence des invocations de fonction et des valeurs de concurrence des autres méthodes d'invocation. Vous pouvez demander la modification de la valeur de concurrence des invocations synchrones de Function Compute.
`FC.ResourceExhausted`	Fonctions limitées en raison de ressources insuffisantes. Contactez-nous pour résoudre ce problème.
`FC.InternalServerError`	Erreur système dans Function Compute. Réexécutez le workflow.
`FC.Unknown`	Function Compute a invoqué la fonction, mais une erreur non gérée s'est produite lors de l'exécution. Exemple de code d'erreur : `UnhandledInvocationError`.
`FC.{ErrorCode}`	Toute autre erreur Function Compute où `{ErrorCode}` représente le code d'erreur spécifique. Consultez la section Codes d'erreur Function Compute.

Erreurs personnalisées

Type d'erreur	Description
`{CustomError}`	Erreurs d'exception personnalisées levées par l'appelé, telles que des erreurs de logique métier dans vos fonctions.

Exemples

Tous les exemples utilisent un état Task qui appelle une fonction Function Compute via FC:InvokeFunction. Remplacez l'espace réservé resourceArn par l'ARN réel de votre fonction :

acs:fc:<region-id>:<account-id>:functions/<function-name>/<version-or-alias>

Espace réservé	Description	Exemple
`<region-id>`	Région où réside la fonction	`cn-hangzhou`
`<account-id>`	ID du compte Alibaba Cloud	Votre ID de compte numérique
`<function-name>`	Nom de la fonction	`myfunction`
`<version-or-alias>`	Version ou alias de la fonction	`LATEST`

Pour plus de détails sur l'obtention de l'ARN de la fonction, consultez la section Obtenir l'ARN de la fonction.

Relance et capture de base

Cet exemple relance MyCustomException1 jusqu'à 3 fois à des intervalles de 2 secondes. Si toutes les relances échouent, la règle de capture construit une sortie d'erreur personnalisée et bascule vers ErrorCatchExit.

Type: StateMachine
Name: ErrorHandleExample
SpecVersion: v1
Description: an example of basic error handling
StartAt: my-error-handle-example
States:
  - Type: Task
    Name: my-error-handle-example
    Action: FC:InvokeFunction
    TaskMode: RequestComplete
    Parameters:
      resourceArn: acs:fc:{regionId}:{accountId}:functions/myfunction/LATEST
      invocationType: Sync
      body: |
        xxx
    Retry:
      - Errors:
          - MyCustomException1
        Description: retry policy 1
        MaxAttempts: 3
        IntervalSeconds: 2
    Catch:
      - Errors:
          - MyCustomException1
        Description: catch policy 1
        OutputConstructor:
          ErrorCode: MyCustomException1
          ErrorMessage: MyCustomException1
        Next: ErrorCatchExit
    Next: SucceededExit
  - Type: Pass
    Name: ErrorCatchExit
    End: true
  - Type: Pass
    Name: SucceededExit
    End: true

Déroulement à l'exécution :

L'état Task exécute FC:InvokeFunction.
Si MyCustomException1 se produit, CloudFlow effectue jusqu'à 3 tentatives, en attendant 2 secondes entre chaque essai.
Si toutes les relances échouent, la règle de capture correspond à MyCustomException1, construit une sortie avec ErrorCode et ErrorMessage, puis bascule vers ErrorCatchExit.
Si aucune erreur ne se produit, le workflow bascule vers SucceededExit.

Remarque

MyCustomException1 est utilisé à titre d'exemple. Vous pouvez modifier le nom de l'erreur en fonction de vos besoins métier.

Relance avec backoff exponentiel

Cet exemple relance MyCustomException2 ou MyCustomException3 jusqu'à 3 fois avec un backoff exponentiel. L'intervalle initial est de 5 secondes et double après chaque tentative (taux de backoff de 2,0).

Type: StateMachine
Name: ErrorHandleExample
SpecVersion: v1
Description: an example of backoff error handling
StartAt: my-error-handle-example
States:
  - Type: Task
    Name: my-error-handle-example
    Action: FC:InvokeFunction
    TaskMode: RequestComplete
    Parameters:
      resourceArn: acs:fc:{regionId}:{accountId}:functions/myfunction/LATEST
      body: xxx
    Retry:
      - Errors:
          - MyCustomException2
          - MyCustomException3
        Description: retry policy 2
        MaxAttempts: 3
        IntervalSeconds: 5
        BackoffRate: 2.0
    Catch:
      - Errors:
          - MyCustomException2
          - MyCustomException3
        Description: catch policy 2
        Next: ErrorCatchExit
    Next: SucceededExit
  - Type: Pass
    Name: ErrorCatchExit
    End: true
  - Type: Pass
    Name: SucceededExit
    End: true

Chronologie des relances :

Le système tente des relances à des intervalles de 5, 10, 20 et 40 secondes, selon le taux de backoff de 2,0.

Si toutes les relances échouent, la règle de capture fait basculer le workflow vers ErrorCatchExit. Aucun OutputConstructor n'est défini ici, donc l'état suivant ne reçoit aucune sortie d'erreur personnalisée.

Politiques multiples de relance et de capture

Cet exemple combine trois niveaux de gestion des erreurs avec différentes stratégies de relance :

MyCustomException1 : relance jusqu'à 3 fois à intervalles fixes de 2 secondes.
MyCustomException2 et MyCustomException3 : relance jusqu'à 3 fois avec backoff exponentiel (initial : 5 s, taux de backoff : 2,0).
FnF.ALL (capture globale) : relance jusqu'à 3 fois avec backoff exponentiel (initial : 5 s, taux de backoff : 2,0), plafonnée à 30 secondes par MaxBackoffSeconds.

Type: StateMachine
Name: ErrorHandleExample
SpecVersion: v1
Description: an example of error handling
StartAt: my-error-handle-example
States:
  - Type: Task
    Name: my-error-handle-example
    Action: FC:InvokeFunction
    TaskMode: RequestComplete
    Parameters:
      resourceArn: acs:fc:{regionId}:{accountId}:functions/myfunction/LATEST
      body: xxx
    Retry:
      - Errors:
          - MyCustomException1
        Description: retry policy 1
        MaxAttempts: 3
        IntervalSeconds: 2
      - Errors:
          - MyCustomException2
          - MyCustomException3
        Description: retry policy 2
        MaxAttempts: 3
        IntervalSeconds: 5
        BackoffRate: 2.0
      - Errors:
          - FnF.ALL
        Description: retry policy 3
        MaxAttempts: 3
        IntervalSeconds: 5
        BackoffRate: 2.0
        MaxBackoffSeconds: 30
    Catch:
      - Errors:
          - MyCustomException1
        Description: catch policy 1
        OutputConstructor:
          ErrorCode: MyCustomException1
          ErrorMessage: MyCustomException1
        Next: ErrorCatchExit
      - Errors:
          - MyCustomException2
          - MyCustomException3
        Description: catch policy 2
        Next: ErrorCatchExit
      - Errors:
          - FnF.ALL
        Description: catch policy 3
        Next: ErrorCatchExit
    Next: SucceededExit
  - Type: Pass
    Name: ErrorCatchExit
    End: true
  - Type: Pass
    Name: SucceededExit
    End: true

Fonctionnement de la correspondance des règles :

CloudFlow évalue les règles de relance et de capture dans l'ordre où elles apparaissent. Pour une erreur qui ne correspond ni à MyCustomException1, ni à MyCustomException2, ni à MyCustomException3, la règle de capture globale FnF.ALL la prend en charge. La relance FnF.ALL utilise MaxBackoffSeconds: 30 pour plafonner l'intervalle, de sorte que le système tente des relances à des intervalles de 5, 10, 20 et 30 secondes.

Après épuisement de toutes les tentatives de relance, la règle de capture correspondante fait basculer le workflow vers ErrorCatchExit.