Problèmes connus concernant Workflows

Cette page répertorie les problèmes connus de 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

Le fait de placer for directement après try entraîne 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 dont la taille dépasse la limite d'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.

HTTP request lost message 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 Call logging level (niveau de journalisation des appels) est défini sur log-all-calls lorsque en utilisant la méthode d'assistance accessString pour récupérer les données des secrets, la valeur secrète n'est pas masquée et est imprimée en texte brut dans les journaux jsonPayload.succeeded.response

Exception d'opération de longue durée lors de l'utilisation d'un 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. 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 d'interrogation LRO, définissez le paramètre de connecteur skip_polling sur true afin que le connecteur d'appel d'appel n'est pas bloquant si la requête initiale aboutit. Une campagne renvoie "done":true. Sinon, pour intercepter les exceptions, utilisez un Structure try/except. Pour en savoir plus, consultez la documentation de référence sur les connecteurs.

Étape suivante

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