Problemas conhecidos do Workflows

Nesta página, listamos problemas conhecidos do Workflows.

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

Posição de for diretamente após try

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

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

No entanto, se você posicionar for após try, a etapa 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}

Esta é a mensagem de erro:

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 dos argumentos

Se você usar o Workflows como destino para um acionador do Eventarc, os eventos maiores que o tamanho máximo de argumentos de fluxos de trabalho não vão acionar execuções de fluxos de trabalho. Para mais informações, consulte Cotas e limites.

HTTP request lost mensagem nos registros

Ao executar um fluxo de trabalho que chama o Cloud Build, seu fluxo de trabalho falha e há uma mensagem HTTP request lost nos registros 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 você encontrar esse erro, tente modificar seu fluxo de trabalho implementando uma política de nova tentativa ou com o tratamento de exceções explícito.

Registro de chamadas e método accessString para extrair dados do secret

Se o nível de registro de chamadas for definido como log-all-calls ao usar o método auxiliar accessString para recuperar dados do secret, o valor do secret não será encoberto 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 de conector do Resource Manager, googleapis.cloudresourcemanager.v3.projects.patch, não retorna um nome de operação de longa duração (LRO, na sigla em inglês). Mesmo para uma solicitação bem-sucedida, uma exceção semelhante à seguinte 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 pesquisa de LRO, defina o parâmetro do conector skip_polling como true para que a chamada de invocação do conector não bloqueie se a solicitação inicial for bem-sucedida. Uma solicitação bem-sucedida retorna "done":true. Caso contrário, para capturar exceções, use uma estrutura try/except. Para mais informações, consulte a Referência de conectores.

A seguir

Confira estratégias úteis para resolver problemas.