Problèmes connus concernant Workflows

Cette page répertorie 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.

Emplacement de for directement après try

Placer for directement après try génère une erreur. Par exemple, une seule étape peut être placée directement après try, comme suit:

- 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 semblable à celui-ci s'affiche dans les journaux:

[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 nouvelle tentative ou via une gestion explicite des exceptions.

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

Si le niveau de journalisation des appels est défini sur log-all-calls lorsque vous utilisez la méthode d'assistance accessString 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 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 de sondage LRO, définissez le paramètre du 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 intercepter les exceptions, utilisez une structure try/except. Pour en savoir plus, consultez la documentation de référence sur les connecteurs.

Étape suivante

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