Problemas conhecidos dos fluxos de trabalho

Esta página lista problemas conhecidos dos fluxos de trabalho.

Também pode verificar se existem problemas ou abrir novos problemas nos rastreadores de problemas públicos.

Posicionamento de for imediatamente após try

Colocar for diretamente após try causa um erro. Por exemplo, pode colocar um único passo diretamente após try, da seguinte forma:

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

No entanto, se posicionar for após try, o passo falha e não pode implementar o fluxo de trabalho. Por 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 é a seguinte:

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

A solução alternativa consiste em adicionar um passo com nome após o try. Por exemplo:

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

Eventos superiores ao tamanho máximo de argumentos

Se usar os fluxos de trabalho como destino de um acionador do Eventarc, os eventos superiores ao tamanho máximo dos argumentos dos fluxos de trabalho não acionam as execuções dos fluxos de trabalho. Para mais informações, consulte o artigo Quotas e limites.

HTTP request lost mensagem nos registos

Quando executa um fluxo de trabalho que chama o Cloud Build, o fluxo de trabalho falha e é apresentada uma mensagem HTTP request lost nos registos semelhante à seguinte:

[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 encontrar este erro, experimente modificar o fluxo de trabalho implementando uma política de repetição ou através do processamento explícito de exceções.

Registo de chamadas e método accessString para obter dados secretos

Se o nível de registo de chamadas estiver definido como log-all-calls quando usar o método auxiliar accessString para obter dados secretos, o valor secreto não é ocultado e é impresso em texto simples nos registos em jsonPayload.succeeded.response.

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

O método do conector do Resource Manager, googleapis.cloudresourcemanager.v3.projects.patch, não devolve um nome de operação de longa duração (LRO). Mesmo para um pedido bem-sucedido, pode ser gerada uma exceção semelhante à seguinte:

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 LRO, defina o parâmetro do conetor skip_polling como true para que a chamada de invocação do conetor não seja bloqueadora se o pedido inicial for bem-sucedido. Um pedido bem-sucedido devolve "done":true; caso contrário, para detetar exceções, use uma estrutura try/except. Para mais informações, consulte a Referência de conectores.

Pedidos HTTP para o Google Kubernetes Engine (GKE)

Todos os clusters do GKE têm um plano de controlo que processa pedidos da API Kubernetes. O plano de controlo tem dois tipos de pontos finais para acesso ao cluster: Pontos finais baseados em DNS e pontos finais baseados em IP. Para mais informações, consulte o artigo Acesso ao plano de controlo.

O Workflows já não suporta pedidos HTTP para os pontos finais baseados em IP dos planos de controlo do cluster do GKE. Para mais informações sobre o âmbito e o impacto desta descontinuação, consulte o anúncio do serviço.

Para garantir que o fluxo de trabalho funciona como esperado, tem de aceder aos pontos finais baseados em DNS. Para aceder aos pontos finais baseados em DNS, recomendamos que use o conector da API Kubernetes num fluxo de trabalho. Para mais informações, consulte o artigo Aceda a objetos da API Kubernetes através de um conetor.

O que se segue?

Conheça estratégias úteis para resolver problemas.