En esta página, se enumeran los problemas conocidos de Workflows.
También puedes verificar los problemas existentes o abrir problemas nuevos desde la herramienta pública de seguimiento de errores.
Posición de for
directamente después de try
Colocar for
justo después de try
genera un error. Por ejemplo, un solo paso
se puede colocar directamente después de try
, de la siguiente manera:
- try: try: call: sys.log args: data: works retry: ${http.default_retry}
Sin embargo, si posicionas for
después de try
, el paso falla y no puedes
implementar el flujo de trabajo. Por ejemplo:
- try: try: for: value: v range: [1,2] steps: - log: call: sys.log args: data: ${v} retry: ${http.default_retry}
Este es el mensaje de error:
Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)
La solución alternativa es agregar un paso con nombre según try
. Por ejemplo:
- try: try: steps: - loopStep: for: value: v range: [1,2] steps: - log: call: sys.log args: data: ${v} retry: ${http.default_retry}
Eventos superiores al tamaño máximo de argumentos
Si usas Workflows como destino para una Activador de Eventarc, eventos superiores al máximo El tamaño de los argumentos de Workflows no activará el flujo de trabajo ejecuciones. Para obtener más información, consulta Cuotas y límites.
Mensaje HTTP request lost
en los registros
Cuando se ejecuta un flujo de trabajo que llama a Cloud Build, el flujo de trabajo falla y
hay un mensaje HTTP request lost
en los registros similar al siguiente:
[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 encuentras este error, intenta modificar tu flujo de trabajo implementando una política de reintento o a través de un control de excepciones explícito.
Registro de llamadas y método accessString
para recuperar datos del Secret
Si el botón
El nivel de registro de llamadas se estableció en
log-all-calls
cuándo
Usa el método auxiliar accessString
para recuperar datos de secretos.
el valor del secreto no se oculta y se imprime como texto sin formato en los registros de
jsonPayload.succeeded.response
Excepción de operación de larga duración cuando se usa el conector de Cloud Resource Manager
El método conector de Resource Manager,
googleapis.cloudresourcemanager.v3.projects.patch
,
no muestra el nombre de una operación de larga duración (LRO). Incluso para una solicitud correcta, es posible que se genere una excepción similar a la siguiente:
exception: "{"message":"Long-running operation returned unexpected response.", "operation":{"done":true,"response":{"@type":"type.googleapis.com/google.cloud.resourcemanager.v3.Project", ... "tags":["ResponseTypeError"]}"
Para evitar un error de sondeo de LRO,
establece el parámetro del conector skip_polling
en true
para que el conector
sin bloqueo si la solicitud inicial se realiza correctamente. Se completó correctamente
la solicitud muestra "done":true
; De lo contrario, para detectar cualquier excepción, usa un
Estructura try/except
.
Para obtener más información, consulta la referencia de conectores.
¿Qué sigue?
Aprende estrategias útiles para solucionar problemas.