Cette page explique comment résoudre les problèmes que vous pouvez rencontrer lors de l'utilisation de Workflows.
Pour en savoir plus, consultez les sections Surveiller et Déboguer des workflows.
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 de console Google Cloud et de gcloud CLI suivants.
Console
Lorsqu'une erreur de déploiement se produit, Workflows affiche le message d'erreur dans une bannière sur la page Modifier le workflow :
Le message d'erreur signale 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
Vous pouvez rencontrer une erreur HTTP 403 (PERMISSION_DENIED) lors de l'exécution d'un workflow, ou lors du déploiement ou de la mise à jour d'un workflow.
Autorisation refusée lors de l'exécution d'un workflow
L'exécution de votre workflow échoue lorsqu'un serveur HTTP répond avec un code d'erreur 403, car le compte de service du workflow ne dispose pas des autorisations nécessaires pour accéder à une ressource cible. Exemple :
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 (Identity and Access Management) lors de sa création. Pour résoudre ce problème, accordez au compte de service du workflow un ou plusieurs rôles IAM contenant les autorisations minimales requises pour accéder aux ressources utilisées par votre workflow. Par exemple, pour permettre à votre workflow d'envoyer des journaux à Cloud Logging, assurez-vous que le compte de service qui exécute le workflow dispose d'un rôle incluant l'autorisation logging.logEntries.create. Pour en savoir plus, consultez Autoriser un workflow à accéder aux ressources Google Cloud .
Autorisation refusée lors du déploiement ou de la mise à jour d'un workflow
Lorsque vous déployez ou mettez à jour un workflow, la requête peut échouer avec une erreur HTTP 403 (PERMISSION_DENIED) si vous n'êtes pas autorisé à agir en tant que compte de service du workflow. Exemple :
Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@ (or it may not exist).
ou
permission iam.serviceAccounts.ActAs is required on the workflow's new/current service account to set it or the workflow source contents
Pour résoudre ce problème, attribuez au compte principal qui déploie ou met à jour le workflow un rôle incluant l'autorisation iam.serviceAccounts.actAs, tel que Utilisateur du compte de service (roles/iam.serviceAccountUser). Selon l'opération, attribuez ce rôle au compte de service suivant :
- Mise à jour du code source du workflow uniquement (sans mettre à jour le compte de service) : attribuez le rôle au compte de service existant associé au workflow.
- Créer un workflow, mettre à jour le compte de service ou mettre à jour le code source et le compte de service : attribuez le rôle au nouveau compte de service que vous associez au workflow.
Pour en savoir plus, consultez la section Autorisations des comptes de service.
Erreurs HTTP 404 No such object ou Not found
Lorsque vous utilisez le connecteur Cloud Storage, l'exécution de votre workflow échoue lorsqu'un serveur HTTP répond avec un code d'erreur 404. Exemple :
HTTP server responded with error code 404 in step "read_input_file", routine "main", line: 13 { "body": "Not Found", "code": 404, ... }
Vous devez encoder les noms d'objets au format URL pour que leur chemin soit sécurisé. Vous pouvez utiliser les fonctions url_encode et url_encode_plus pour encoder les caractères applicables lorsqu'ils apparaissent dans le nom de l'objet ou dans la chaîne de requête d'une URL de requête. Exemple :
- init: assign: - source_bucket: "my-bucket" - file_name: "my-folder/my-file.json" - list_objects: call: googleapis.storage.v1.objects.get args: bucket: ${source_bucket} object: ${text.url_encode(file_name)} alt: media result: r - returnStep: return: ${r}
Si vous n'encodez pas le nom de votre objet au format URL et que votre bucket de stockage comporte des dossiers, la requête échouera. Pour en savoir plus, consultez Encoder des parties de chemin d'URL et Remarques sur l'attribution de noms dans Cloud Storage.
Erreurs HTTP 429 Too many requests
Il existe un nombre maximal d'exécutions de workflow actives pouvant s'exécuter simultanément. Une fois ce quota épuisé, et si le backlog d'exécution est désactivé ou si le quota d'exécutions en attente est atteint, toutes les nouvelles exécutions échouent avec un code d'état HTTP 429 Too many requests.
La mise en file d'attente des exécutions vous permet de mettre en file d'attente les exécutions de workflow une fois que le quota d'exécutions simultanées 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), à l'exception des suivantes :
- Lorsque vous créez une exécution à l'aide d'un connecteur
executions.runouexecutions.createdans un workflow, le backlog d'exécution est désactivé par défaut. Vous pouvez le configurer en définissant explicitement le champdisableConcurrencyQuotaOverflowBufferingde l'exécution surfalse. - Pour les exécutions déclenchées par Pub/Sub, le backlog d'exécution est désactivé et ne peut pas être configuré.
Pour en savoir plus, consultez Gérer l'accumulation d'exécutions.
Vous pouvez également activer une file d'attente Cloud Tasks pour exécuter des workflows enfants à un taux que vous définissez et obtenir un meilleur taux d'exécution. Dans ce cas, vous pouvez désactiver explicitement le backlog d'exécution.
Erreurs d'autorisation de compte de service multiprojet
Si vous recevez une erreur PERMISSION_DENIED lorsque vous tentez 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 en savoir plus, consultez Déployer un workflow avec un compte de service multiprojet.
Le nom de la ressource doit être conforme au document RFC 1123
L'exécution de votre workflow échoue lorsqu'un serveur HTTP répond avec un code d'erreur 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 la norme d'étiquette DNS définie dans la RFC 1123 et que, lors de l'attribution de variables, vous concaténez correctement les chaînes et les expressions.
Par exemple, vous ne pouvez pas attribuer une variable comme suit : - 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 des deux-points peuvent entraîner un comportement inattendu lorsque les deux-points sont interprétés comme définissant un mappage. Bien qu'il soit possible de déployer et d'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 , il ne peut pas être affiché visuellement dans la console Google Cloud , et vous pouvez recevoir un avertissement semblable à celui-ci :
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)}
Clés de carte utilisant des 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 dans "special!key": value), vous devez placer le nom de la clé entre guillemets. Si le nom de la clé n'est pas entouré de guillemets, le workflow ne peut pas être déployé. Par exemple, si vous essayez de déployer le code source suivant, une erreur 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
L'utilisation de plusieurs expressions dans une liste, comme dans l'exemple de plage d'itération suivant, n'est pas un code YAML valide :
[${rangeStart}, ${rangeEnd}])
Pour résoudre ce problème, vous pouvez effectuer l'une des opérations suivantes :
Placez la liste dans une expression :
${[rangeStart, rangeEnd]}Placez 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 les différents problèmes et indique comment les résoudre.
| Problème | Description |
|---|---|
L'autorisation cloudkms.cryptoKeyVersions.useToEncrypt est refusée |
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 fourni est différente de celle du workflow.
Solution : utilisez un trousseau de clés Cloud KMS et un workflow protégé 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 Workflows. |
| La limite de quota Cloud KMS est dépassée | Vous avez atteint votre quota de requêtes Cloud KMS.
Solution : limitez le nombre d'appels Cloud KMS ou augmentez la limite de quota. Pour en savoir plus, consultez la page Quotas Cloud KMS. |
Entité demandée introuvable lors de l'utilisation du connecteur Cloud Run
L'exécution de votre workflow échoue lorsqu'un serveur HTTP répond avec un code d'erreur 404 lors d'une tentative d'utilisation de la méthode de 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, cet emplacement n'accepte que les méthodes de liste.
Pour résoudre ce problème, veillez à spécifier un argument location lorsque vous appelez 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 erreur telle que ResourceLimitError, MemoryLimitExceededError ou ResultSizeLimitExceededError, vous pouvez libérer de la mémoire en effaçant les variables.
Par exemple, vous pouvez libérer de 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
La mise en retrait YAML est significative et doit comporter au moins deux espaces par niveau d'indentation. Une mise en retrait insuffisante peut entraîner des erreurs, et un nouveau niveau doit être décalé d'au moins deux espaces par rapport au début du texte de la ligne précédente.Par exemple, l'exemple suivant spécifie de manière incorrecte un élément de liste contenant un mappage 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 tabulations pour mettre en retrait les lignes.