Problemas conocidos de Workflows

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.

Colocación de for directamente después de try

Si colocas for directamente después de try, se produce 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 colocas for después de try, el paso fallará y no podrás 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 después de 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 que superan el tamaño máximo de argumentos

Si usas Workflows como destino para un activador de Eventarc, los eventos que superen el tamaño máximo de argumentos de Workflows no activarán las ejecuciones de flujos de trabajo. Para obtener más información, consulta Cuotas y límites.

Mensaje HTTP request lost en los registros

Cuando ejecutas un flujo de trabajo que llama a Cloud Build, este falla y aparece un mensaje de 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 reintentos o a través del control de excepciones explícito.

Registro de llamadas y método accessString para recuperar datos secretos

Si el nivel de registro de llamadas se establece en log-all-calls cuando se usa el método auxiliar accessString para recuperar datos secretos, el valor secreto no se oculta y se imprime en texto sin formato en los registros en jsonPayload.succeeded.response.

Excepción de operación de larga duración cuando se usa el conector de Cloud Resource Manager

El método del conector de Resource Manager, googleapis.cloudresourcemanager.v3.projects.patch, no devuelve un nombre de operación de larga duración (LRO). Incluso para una solicitud exitosa, 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 la llamada de invocación del conector no se bloquee si la solicitud inicial se realiza correctamente. Una solicitud correcta devuelve "done":true; de lo contrario, para detectar cualquier excepción, usa una estructura try/except. Para obtener más información, consulta la referencia de Connectors.

Solicitudes HTTP a Google Kubernetes Engine (GKE)

Cada clúster de GKE tiene un plano de control que controla las solicitudes de la API de Kubernetes. El plano de control tiene dos tipos de extremos para el acceso al clúster: extremos basados en DNS y extremos basados en IP. Para obtener más información, consulta Acceso al plano de control.

Workflows ya no admite solicitudes HTTP a los extremos basados en IP de los planos de control de clúster de GKE. Para obtener más información sobre el alcance y el impacto de esta baja, consulta el anuncio del servicio.

Para asegurarte de que tu flujo de trabajo funcione según lo previsto, debes acceder a los extremos basados en DNS. Para acceder a los extremos basados en DNS, te recomendamos que uses el conector de la API de Kubernetes en un flujo de trabajo. Para obtener más información, consulta Cómo acceder a objetos de la API de Kubernetes con un conector.

¿Qué sigue?

Conoce estrategias útiles para solucionar problemas.