Problèmes connus concernant Workflows

Cette page liste les problèmes connus liés aux workflows.

Vous pouvez également consulter les problèmes existants ou signaler de nouveaux problèmes dans les outils publics de suivi des problèmes.

Placement de for directement après try

Placer for directement après try entraîne une erreur. Par exemple, une seule étape peut être placée directement après try, comme ceci :

- try:
    try:
      call: sys.log
      args:
        data: works
    retry: ${http.default_retry}

Toutefois, si vous placez for après try, l'étape échoue et vous ne pouvez pas déployer le workflow. Exemple :

- try:
    try:
      for:
        value: v
        range: [1,2]
        steps:
          - log:
              call: sys.log
              args:
                data: ${v}
    retry: ${http.default_retry}

Le message d'erreur est le suivant :

Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)

Pour contourner ce problème, ajoutez une étape nommée après try. Exemple :

- try:
    try:
      steps:
        - loopStep:
            for:
              value: v
              range: [1,2]
              steps:
                - log:
                    call: sys.log
                    args:
                      data: ${v}
    retry: ${http.default_retry}

Événements supérieurs à la taille maximale des arguments

Si vous utilisez Workflows comme destination d'un déclencheur Eventarc, les événements supérieurs à la taille maximale de l'argument Workflows ne déclenchent pas d'exécution de workflow. Pour en savoir plus, consultez la page Quotas et limites.

Message HTTP request lost dans les journaux

Lorsque vous exécutez un workflow qui appelle Cloud Build, votre workflow échoue et un message HTTP request lost s'affiche dans les journaux, semblable à ce qui suit :

[1500] HTTP request lost
INTERNAL MESSAGE: HTTP request lost
...
CAUSED BY:
RPC::UNREACHABLE: RPC connection timed out: FDD 20s, last read 2022-10-14 16:39:04 -0700 PDT

Si vous rencontrez cette erreur, essayez de modifier votre workflow en implémentant une stratégie de répétition des tentatives ou en utilisant une gestion des exceptions explicite.

Journalisation des appels et méthode accessString pour récupérer les données secrètes

Si le niveau de journalisation des appels est défini sur log-all-calls lorsque la méthode d'assistance accessString est utilisée pour récupérer des données secrètes, la valeur secrète n'est pas masquée et est imprimée en texte brut dans les journaux de jsonPayload.succeeded.response.

Exception d'opération de longue durée lors de l'utilisation du connecteur Cloud Resource Manager

La méthode du connecteur Resource Manager, googleapis.cloudresourcemanager.v3.projects.patch, ne renvoie pas de nom d'opération de longue durée (LRO). Même pour une requête réussie, une exception semblable à celle ci-dessous peut être générée :

exception: "{"message":"Long-running operation returned unexpected response.",
"operation":{"done":true,"response":{"@type":"type.googleapis.com/google.cloud.resourcemanager.v3.Project",
...
"tags":["ResponseTypeError"]}"

Pour éviter une erreur d'interrogation d'une opération de longue durée, définissez le paramètre de connecteur skip_polling sur true afin que l'appel d'invocation du connecteur ne soit pas bloquant si la requête initiale aboutit. Une requête réussie renvoie "done":true. Sinon, pour détecter les exceptions, utilisez une structure try/except. Pour en savoir plus, consultez la documentation de référence sur les connecteurs.

Requêtes HTTP adressées à Google Kubernetes Engine (GKE)

Chaque cluster GKE dispose d'un plan de contrôle qui gère les requêtes de l'API Kubernetes. Le plan de contrôle comporte deux types de points de terminaison pour l'accès au cluster : les points de terminaison basés sur le DNS et les points de terminaison basés sur l'adresse IP. Pour en savoir plus, consultez Accès au plan de contrôle.

Workflows n'est plus compatible avec les requêtes HTTP vers les points de terminaison basés sur l'adresse IP des plans de contrôle des clusters GKE. Pour en savoir plus sur le champ d'application et l'impact de cet abandon, consultez l'annonce du service.

Pour vous assurer que votre workflow fonctionne comme prévu, vous devez accéder aux points de terminaison basés sur le DNS. Pour accéder aux points de terminaison basés sur le DNS, nous vous recommandons d'utiliser le connecteur d'API Kubernetes dans un workflow. Pour en savoir plus, consultez Accéder aux objets de l'API Kubernetes à l'aide d'un connecteur.

Étapes suivantes

Découvrez les stratégies utiles pour résoudre les problèmes.