Problemas conocidos de Workflows

En esta página se enumeran los problemas conocidos de Workflows.

También puedes buscar problemas o abrir nuevos en las herramientas de seguimiento de incidencias públicas.

Colocación de for directamente después de try

Si coloca for directamente después de try, se producirá un error. Por ejemplo, se puede colocar un solo paso directamente después de try, de esta forma:

- try:
    try:
      call: sys.log
      args:
        data: works
    retry: ${http.default_retry}

Sin embargo, si colocas 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}

El mensaje de error es el siguiente:

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 añadir 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 los argumentos

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

HTTP request lost mensaje en los registros

Cuando ejecutas un flujo de trabajo que llama a Cloud Build, se produce un error y aparece 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 se produce este error, prueba a modificar tu flujo de trabajo implementando una política de reintentos o mediante una gestión de excepciones explícita.

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

Si el nivel de registro de llamadas se define como log-all-calls cuando se usa el método auxiliar accessString para recuperar datos secretos, el valor 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 al usar el conector de Cloud Resource Manager

El método del conector Resource Manager, googleapis.cloudresourcemanager.v3.projects.patch, no devuelve un nombre de operación de larga duración (LRO). Incluso si la solicitud se realiza correctamente, puede producirse 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, asigna el valor true al parámetro skip_polling del conector para que la llamada de invocación del conector no se bloquee si la solicitud inicial se realiza correctamente. Si la solicitud se realiza correctamente, se devuelve "done":true. De lo contrario, para detectar excepciones, usa una estructura try/except. Para obtener más información, consulta la referencia de conectores.

Solicitudes HTTP a Google Kubernetes Engine (GKE)

Todos los clústeres de GKE tienen un plano de control que gestiona las solicitudes de la API de Kubernetes. El plano de control tiene dos tipos de endpoints para acceder al clúster: endpoints basados en DNS y endpoints basados en IP. Para obtener más información, consulta Acceso al plano de control.

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

Para asegurarte de que tu flujo de trabajo funciona correctamente, debes acceder a los endpoints basados en DNS. Para acceder a los endpoints 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 Acceder a objetos de la API de Kubernetes mediante un conector.

Siguientes pasos

Consulta estrategias útiles para solucionar problemas.