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 la console Google Cloud suivante et gcloud CLI.

Console

En cas d'erreur de déploiement, Workflows affiche l'erreur message dans une bannière sur la page Modifier le workflow: Erreur de déploiement 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).

ou

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 niveau l'heure de création du workflow. 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 executions.run ou executions.create dans un workflow, le backlogging des exécutions est désactivé par défaut. Vous pouvez configurez-le en définissant explicitement le champ disableConcurrencyQuotaOverflowBuffering 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 rythme que vous définissez et atteignez un meilleur taux d'exécution ; dans ce cas, vous voudrez peut-être explicitement désactiver le backlogging d'exécution.

Erreurs d'autorisation de compte de service inter-projets

Si une erreur PERMISSION_DENIED s'affiche lorsque vous essayez d'utiliser un compte de service inter-projets pour déployer un workflow, assurez-vous que La contrainte booléenne iam.disableCrossProjectServiceAccountUsage n'est pas appliquée pour 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 Workflows Le tableau suivant décrit différents problèmes et 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 :

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 le workflow de ML.

Solution: utilisez un trousseau de clés Cloud KMS protégé de la même région. Notez qu'ils peuvent se trouver dans différentes projects.) Pour en savoir plus, consultez Emplacements Cloud KMS Emplacements des workflows.

La limite de quota Cloud KMS est dépassée Vous avez atteint votre limite de quota pour les requêtes Cloud KMS.

Solution: limitez le nombre d'appels Cloud KMS ou d'augmenter la limite de quota. Pour en savoir plus, consultez Quotas Cloud KMS

L'entité demandée est introuvable lors de l'utilisation du connecteur Cloud Run

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

Cette méthode nécessite que vous spécifiiez l'emplacement du point de terminaison HTTP. Pour 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 à appeler le connecteur. Pour connaître les options d'emplacement de l'API Cloud Run Admin, consultez points de terminaison de service.

Limites de ressources

Si vous rencontrez des limites de ressources ou une d'erreur comme ResourceLimitError, MemoryLimitExceededError ou ResultSizeLimitExceededError, vous pouvez libérer de la mémoire des variables de suppression. Par exemple, vous pouvez libérer de la mémoire qui est nécessaire pour les opérations suivantes étapes. Vous pouvez aussi avoir des appels dont les résultats ne vous intéressent pas, omettre ces résultats totalement.

Retrait YAML

L'indentation YAML est pertinente 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, le code suivant indique à tort un élément de liste contenant une carte avec 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 caractères de tabulation, pour mettre en retrait les lignes.

Étape suivante