Problemas conhecidos do Workflows

Esta página lista os problemas conhecidos do Workflows.

Você também pode verificar problemas existentes ou abrir novos nos issue trackers públicos.

Posicionamento de for diretamente após try

Colocar for diretamente após try causa um erro. Por exemplo, uma única etapa pode ser colocada diretamente após try, assim:

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

No entanto, se você posicionar for depois de try, a etapa vai falhar, e não será possível implantar o fluxo de trabalho. Exemplo:

- try:
    try:
      for:
        value: v
        range: [1,2]
        steps:
          - log:
              call: sys.log
              args:
                data: ${v}
    retry: ${http.default_retry}

A mensagem de erro é esta:

Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)

A solução alternativa é adicionar uma etapa nomeada após o try. Exemplo:

- try:
    try:
      steps:
        - loopStep:
            for:
              value: v
              range: [1,2]
              steps:
                - log:
                    call: sys.log
                    args:
                      data: ${v}
    retry: ${http.default_retry}

Eventos maiores que o tamanho máximo de argumentos

Ao usar o Workflows como destino para um gatilho do Eventarc, eventos maiores que o tamanho máximo de argumentos do Workflows não acionarão as execuções de fluxo de trabalho. Para mais informações, consulte Cotas e limites.

Mensagem HTTP request lost nos registros

Ao executar um fluxo de trabalho que chama o Cloud Build, ele falha e há uma mensagem HTTP request lost nos registros semelhante a esta:

[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

Se você encontrar esse erro, tente modificar seu fluxo de trabalho implementando uma política de nova tentativa ou um tratamento de exceções explícito.

Registro de chamadas e método accessString para recuperar dados secretos

Se o nível de registro de chamadas estiver definido como log-all-calls ao usar o método auxiliar accessString para recuperar dados secretos, o valor secreto não será editado e será impresso em texto simples nos registros em jsonPayload.succeeded.response.

Exceção de operação de longa duração ao usar o conector do Cloud Resource Manager

O método do conector do Resource Manager, googleapis.cloudresourcemanager.v3.projects.patch, não retorna um nome de operação de longa duração (LRO). Mesmo para uma solicitação bem-sucedida, uma exceção semelhante a esta pode ser gerada:

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 um erro de sondagem de LRO, defina o parâmetro do conector skip_polling como true para que a chamada de invocação do conector não seja bloqueada se a solicitação inicial for bem-sucedida. Uma solicitação bem-sucedida retorna "done":true. Caso contrário, para detectar exceções, use uma estrutura try/except. Para mais informações, consulte a Referência de conectores.

Solicitações HTTP para o Google Kubernetes Engine (GKE)

Todos cluster do GKE têm um plano de controle que processa solicitações da API Kubernetes. O plano de controle tem dois tipos de endpoints para acesso ao cluster: endpoints baseados em DNS e endpoints baseados em IP. Para mais informações, consulte Acesso ao plano de controle.

Workflows não são mais compatíveis com solicitações HTTP para os endpoints baseados em IP dos planos de controle de cluster do GKE. Para mais informações sobre o escopo e o impacto dessa descontinuação, consulte o comunicado do serviço.

Para garantir que seu fluxo de trabalho funcione conforme o esperado, acesse os endpoints baseados em DNS. Para acessar os endpoints baseados em DNS, recomendamos usar o conector da API do Kubernetes em um fluxo de trabalho. Para mais informações, consulte Acessar objetos da API Kubernetes usando um conector.

A seguir

Aprenda estratégias úteis para resolver problemas.