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.
Positionnement de for juste après try
Si vous placez for juste après try, une erreur est générée. Par exemple, vous pouvez placer une étape unique directement après try, comme ceci:
- try:
try:
call: sys.log
args:
data: works
retry: ${http.default_retry}
Toutefois, si vous positionnez 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)
La solution consiste à ajouter 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 autorisée pour les arguments
Si vous utilisez Workflows comme destination pour un déclencheur Eventarc, les événements dont la taille est supérieure à la taille maximale des arguments Workflows ne déclencheront pas d'exécutions 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, celui-ci é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 règle de nouvelle tentative ou en utilisant explicitement la gestion des exceptions.
La journalisation des appels et la méthode accessString pour récupérer les données sur les secrets
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 les données des secrets, la valeur du secret n'est pas masquée et est imprimée en texte brut dans les journaux dans 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 en cas de réussite de la requête, une exception semblable à la suivante 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 de longue durée, définissez le paramètre de connecteur skip_polling sur true afin que l'appel 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.
Étapes suivantes
Découvrez des stratégies utiles pour résoudre les problèmes.