Cette page a été traduite par l'API Cloud Translation.

Résoudre des problèmes

Cette page explique comment résoudre les problèmes que vous pouvez rencontrer lors de l'utilisation Workflows

Pour en savoir plus, consultez Surveillance et Workflows de débogage.

Erreurs de déploiement

Lorsqu'un workflow est déployé, Workflows vérifie que le code source est exempt d'erreurs et correspond à la syntaxe du langage. Workflows renvoie une erreur s'il en existe une. Les types d'erreurs de déploiement les plus courants sont les suivants:

Référencer une variable, une étape ou un sous-workflow indéfini
Syntaxe incorrecte
- Mise en retrait incorrecte
- Éléments {, }, ", - ou : manquants ou superflus

Par exemple, le code source suivant génère une erreur de déploiement, car l'instruction return fait référence à une variable non définie, varC:

- step1:
    assign:
    - varA: "Hello"
    - varB: "World"
- step2:
    return: ${varC + varB}

Ce code source incorrect est utilisé dans les exemples suivants de Google Cloud Console et de la CLI gcloud.

Console

En cas d'erreur de déploiement, Workflows affiche l'erreur message dans une bannière sur la page Modifier le workflow: Le message d'erreur indique le problème dans le code source, en spécifiant l'origine de l'erreur lorsque cela est possible:

Could not deploy workflow: failed to build: error in step step2: error
evaluating return value: symbol 'varC' is neither a variable nor a
sub-workflow name (Code: 3)

gcloud

Lorsque vous exécutez la commande gcloud workflows deploy, Workflows renvoie un message d'erreur à la ligne de commande si le déploiement échoue. Le message d'erreur signale le problème dans le code source, en spécifiant l'origine de l'erreur lorsque cela est possible:

ERROR: (gcloud.workflows.deploy) [INVALID_ARGUMENT] failed to build:
error in step step2: error evaluating return value: symbol 'varC' is neither
a variable nor a sub-workflow name

Pour résoudre le problème, modifiez le code source du workflow. Dans ce cas, reportez-vous à varA au lieu de varC.

Erreurs d'autorisation du compte de service HTTP `403`

L'exécution de votre workflow échoue lorsqu'un serveur HTTP répond par un code d'erreur sur 403. Exemple :

Permission 'iam.serviceaccounts.actAs' denied on service
account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).

SERVICE_ACCOUNT does not have storage.objects.create access to the Google Cloud
Storage object. Permission 'storage.objects.create' denied on resource (or it may not exist).

Chaque workflow est associé à un compte de service IAM au moment de sa création. Pour résoudre ce problème, vous devez accorder au service compte un ou plusieurs rôles IAM contenant le minimum les autorisations requises pour gérer votre flux de travail. Par exemple, si vous souhaitez autoriser votre workflow, envoyez des journaux à Cloud Logging, assurez-vous que le compte de service exécutant le workflow s'est vu attribuer un rôle comprenant le rôle Autorisation logging.logEntries.create. Pour en savoir plus, consultez Autoriser un workflow à accéder aux ressources Google Cloud

Erreurs HTTP `429 Too many requests`

Le nombre maximal de workflows actifs est maximal. qui peuvent s'exécuter simultanément. Une fois ce quota épuisé, la journalisation des exécutions en attente est désactivée, ou si le quota d'exécutions en attente est les nouvelles exécutions échouent avec l'état HTTP 429 Too many requests. du code source.

Le backlog d'exécution vous permet de mettre en file d'attente les exécutions de workflow une fois que d'exécutions est atteint. Par défaut, le backlog d'exécution est activé pour toutes les requêtes (y compris celles déclenchées par Cloud Tasks) avec les exceptions suivantes:

Lorsque vous créez une exécution à l'aide d'un connecteur executions.run ou executions.create dans un workflow, le report des exécutions est désactivé par défaut. Vous pouvez le configurer en définissant explicitement le champ disableConcurrencyQuotaOverflowBuffering de l'exécution sur false.
Pour les exécutions déclenchées par Pub/Sub, le backlogging des exécutions est désactivé et ne peut pas être configuré.

Pour en savoir plus, consultez Gérer le backlog d'exécution

Vous pouvez également activer une file d'attente Cloud Tasks pour exécuter des workflows enfants à un débit que vous définissez et obtenir un meilleur débit d'exécution. Dans ce cas, vous pouvez désactiver explicitement le journalisation de l'exécution.

Erreurs d'autorisation de compte de service inter-projets

Si vous recevez une erreur PERMISSION_DENIED lorsque vous essayez d'utiliser un compte de service multiprojet pour déployer un workflow, assurez-vous que la contrainte booléenne iam.disableCrossProjectServiceAccountUsage n'est pas appliquée à votre projet et que vous avez correctement configuré le compte de service. Pour Pour en savoir plus, consultez la section Déployer un workflow avec un service inter-projets compte.

Le nom de la ressource doit être conforme à la norme RFC 1123

L'exécution de votre workflow échoue lorsqu'un serveur HTTP répond par un code d'erreur sur 400. Exemple :

"description": "must conform to RFC 1123: only lowercase, digits, hyphens,
and periods are allowed, must begin and end with letter or digit, and less
than 64 characters."

Pour résoudre ce problème, assurez-vous que le nom de votre ressource respecte l'étiquette DNS standard telle que définie dans RFC 1123, et que lors de l'affectation de variables, vous concaténez strings et expressions correctement.

Par exemple, vous ne pouvez pas attribuer une variable de ce type: - string: hello-${world}. Procédez plutôt comme suit :

YAML

  - assign_vars:
      assign:
          - string: "hello"
          - string: ${string+" "+"world"}

JSON

  [
    {
      "assign_vars": {
        "assign": [
          {
            "string": "hello"
          },
          {
            "string": "${string+" "+"world"}"
          },
        ]
      }
    }
  ]

Expressions contenant deux points

En YAML, les expressions contenant deux points peuvent entraîner un comportement inattendu lorsque le signe deux-points est interprété comme une définition de carte. Bien qu'il soit possible de déployer et exécuter le workflow, le résultat ne sera pas celui attendu.

Si vous créez un workflow à l'aide de la console Google Cloud, vous ne pouvez pas affichée dans la console Google Cloud, et vous pouvez recevoir d'avertissement semblable à celui-ci:

Avertissement concernant la création de workflows

Vous pouvez résoudre ce problème en encapsulant l'expression YAML entre guillemets simples:

recommandée : '${"a: " +string(a)}'

Option déconseillée : ${"a: " +string(a)}

Mapper les clés à l'aide de caractères non alphanumériques

Lorsque vous accédez à des clés de mappage contenant des caractères non alphanumériques (par exemple, le point d'exclamation par "special!key": value), vous devez encapsuler le nom de la clé de devis. Si le nom de la clé n'est pas entre guillemets, le workflow ne peut pas déployés. Par exemple, si vous essayez de déployer le code source suivant, une exception token recognition error est générée :

- init:
    assign:
    - var:
        key:
            "special!key": bar
- returnOutput:
    return: '${"foo" + var.key[special!key]}'

Pour résoudre ce problème, utilisez plutôt le code suivant pour renvoyer le résultat:

'${"foo" + var.key["special!key"]}'

Plusieurs expressions dans une liste

Utiliser plusieurs expressions dans une liste, comme ceci : Plage d'itération exemple n'est pas un fichier YAML valide:

[${rangeStart}, ${rangeEnd}])

Vous pouvez résoudre ce problème de l'une des façons suivantes:

Placez la liste dans une expression:

${[rangeStart, rangeEnd]}
Encapsulez chaque expression entre guillemets simples:

['${rangeStart}', '${rangeEnd}']

Le résultat est alors une liste de deux valeurs, comme prévu.

Clés de chiffrement gérées par le client (CMEK)

Vous pouvez rencontrer des erreurs lorsque vous utilisez Cloud KMS avec des workflows. Le tableau suivant décrit les différents problèmes et indique comment les résoudre.

Problème	Description
L'autorisation `cloudkms.cryptoKeyVersions.useToEncrypt` est refusé	Soit la clé Cloud KMS fournie n'existe pas, soit l'autorisation n'est pas correctement configurée. Solution : Vérifiez que la clé Cloud KMS existe. Listez les clés d'un trousseau de clés spécifié et vérifiez son utilisation. Assurez-vous que l'agent de service Workflows a à la clé et dispose du rôle `cloudkms.cryptoKeyEncrypterDecrypter`.
La version de clé n'est pas activée	La version de clé Cloud KMS fournie a été désactivée. Solution : Réactivez la version de clé Cloud KMS.
La région du trousseau de clés ne correspond pas à la ressource à protéger	La région du trousseau de clés KMS fournie est différente de celle du workflow. Solution: utilisez un trousseau de clés Cloud KMS protégé du workflow de ML de la même région. (Notez qu'ils peuvent se trouver dans des projets différents.) Pour en savoir plus, consultez les pages Emplacements Cloud KMS et Emplacements des workflows.
La limite de quota Cloud KMS est dépassée	Votre limite de quota pour les requêtes Cloud KMS a été atteinte. Solution: limitez le nombre d'appels Cloud KMS ou d'augmenter la limite de quota. Pour en savoir plus, consultez la page Quotas Cloud KMS.

L'entité demandée est introuvable lorsque vous utilisez le connecteur Cloud Run

L'exécution de votre workflow échoue lorsqu'un serveur HTTP répond avec un code d'erreur 404 lorsque vous essayez d'utiliser la méthode du connecteur, googleapis.run.v1.namespaces.jobs.create.

Cette méthode nécessite de spécifier l'emplacement du point de terminaison HTTP. Par exemple, us-central1 ou asia-southeast1. Si vous ne spécifiez pas d'emplacement, le point de terminaison global https://run.googleapis.com est utilisé ; Toutefois, ce lieu n'est compatible qu'avec les méthodes "list".

Pour résoudre ce problème, veillez à spécifier un argument location lorsque vous appelez le connecteur. Pour connaître les options de localisation de l'API Cloud Run Admin, consultez les points de terminaison de service.

Limites de ressources

Si vous rencontrez des limites de ressources ou une erreur telle que ResourceLimitError, MemoryLimitExceededError ou ResultSizeLimitExceededError, vous pouvez libérer de la mémoire en effaçant des variables. Par exemple, vous pouvez libérer la mémoire nécessaire pour les étapes suivantes. Vous pouvez également avoir des appels dont les résultats ne vous intéressent pas, et vous pouvez les omettre complètement.

Indentation YAML

Le retrait YAML est significatif et doit comporter au moins deux espaces par niveau de retrait. Une mise en retrait insuffisante peut provoquer des erreurs et un nouveau niveau doit comporter au moins deux espaces le début du texte à la ligne précédente ;

Par exemple, l'élément de liste suivant spécifie de manière incorrecte une carte contenant des éléments stepName et call :

- stepName:
  call: sys.log

Vous devez plutôt mettre en retrait la ligne suivante de deux espaces pour imbriquer call. dans stepName:

- stepName:
    call: sys.log

Veillez à utiliser des espaces plutôt que des tabulations pour mettre les lignes en retrait.

Étape suivante

Problèmes connus concernant Workflows