O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Resolver problemas

Nesta página, mostramos como resolver problemas que podem ocorrer ao usar o Workflows.

Para mais informações, consulte monitoramento e depuração Workflows.

Erros de implantação

Quando um fluxo de trabalho é implantado, o Workflows verifica se o código-fonte não tem erros e corresponde à sintaxe da linguagem. Caso haja algum, o Workflows retorna um erro. Os tipos mais comuns de erros de implantação são:

Referenciar uma variável, etapa ou subfluxo de trabalho indefinido
Sintaxe incorreta
- Recuo incorreto
- {, }, ", - ou : ausentes ou irrelevantes

Por exemplo, o código-fonte a seguir gera um erro de implantação porque a instrução de retorno referencia uma variável indefinida, varC:

- step1:
    assign:
    - varA: "Hello"
    - varB: "World"
- step2:
    return: ${varC + varB}

Esse código-fonte incorreto é usado nos seguintes exemplos do console do Google Cloud e da CLI gcloud.

Console

Quando ocorre um erro de implantação, o Workflows exibe a mensagem de erro em um banner na página Editar fluxo de trabalho: A mensagem de erro sinaliza o problema no código-fonte, especificando a origem do erro quando possível:

Could not deploy workflow: failed to build: error in step step2: error
evaluating return value: symbol 'varC' is neither a variable nor a
sub-workflow name (Code: 3)

gcloud

Quando você executa o comando gcloud workflows deploy, o Workflows retorna uma mensagem de erro para a linha de comando se a implantação falhar. A mensagem de erro sinaliza o problema no código-fonte, especificando a origem do erro quando possível:

ERROR: (gcloud.workflows.deploy) [INVALID_ARGUMENT] failed to build:
error in step step2: error evaluating return value: symbol 'varC' is neither
a variable nor a sub-workflow name

Para resolver o problema, edite o código-fonte do fluxo de trabalho. Nesse caso, consulte varA em vez de varC.

Erros de permissão da conta de serviço HTTP `403`

Você pode encontrar um erro de HTTP 403 (PERMISSION_DENIED) ao executar, implantar ou atualizar um fluxo de trabalho.

Permissão negada ao executar um fluxo de trabalho

A execução do fluxo de trabalho falha quando um servidor HTTP responde com um código do erro 403 porque a conta de serviço do fluxo de trabalho não tem permissão para acessar um recurso de destino. Exemplo:

SERVICE_ACCOUNT does not have storage.objects.create access to the Google Cloud
Storage object. Permission 'storage.objects.create' denied on resource (or it may not exist).

Cada fluxo de trabalho é associado a uma conta de serviço do Identity and Access Management (IAM) no momento da criação. Para resolver esse problema, conceda à conta de serviço do fluxo de trabalho um ou mais papéis do IAM que contenham as permissões mínimas necessárias para acessar os recursos usados pelo fluxo de trabalho. Por exemplo, para permitir que o fluxo de trabalho envie registros ao Cloud Logging, verifique se a conta de serviço que executa o fluxo de trabalho recebeu um papel que inclua a permissão logging.logEntries.create. Para mais informações, consulte Conceder permissão a um fluxo de trabalho para acessar recursos do Google Cloud .

Permissão negada ao implantar ou atualizar um fluxo de trabalho

Ao implantar ou atualizar um fluxo de trabalho, a solicitação poderá falhar com um erro HTTP 403 (PERMISSION_DENIED) se você não tiver permissão para atuar como a conta de serviço do fluxo de trabalho. Exemplo:

Permission 'iam.serviceaccounts.actAs' denied on service
account PROJECT_NUMBER-compute@ (or it may not exist).

permission iam.serviceAccounts.ActAs is required on the workflow's new/current
service account to set it or the workflow source contents

Para resolver esse problema, conceda ao principal que está implantando ou atualizando o fluxo de trabalho um papel que inclua a permissão iam.serviceAccounts.actAs, como Usuário da conta de serviço (roles/iam.serviceAccountUser). Dependendo da operação, conceda esse papel na seguinte conta de serviço:

Atualizar apenas o código-fonte do fluxo de trabalho (sem atualizar a conta de serviço): conceda o papel na conta de serviço atual associada ao fluxo de trabalho.
Criar um fluxo de trabalho, atualizar a conta de serviço ou atualizar o código-fonte e a conta de serviço: conceda o papel na nova conta de serviço que você está associando ao fluxo de trabalho.

Para mais informações, consulte Permissões de contas de serviço.

Erros HTTP `404 No such object` ou `Not found`

Ao usar o conector do Cloud Storage, a execução do fluxo de trabalho falha quando um servidor HTTP responde com um código de erro 404. Exemplo:

HTTP server responded with error code 404
in step "read_input_file", routine "main", line: 13
{
  "body": "Not Found",
  "code": 404,
  ...
}

É preciso codificar os nomes dos objetos em URL para que o caminho seja seguro. É possível usar as funções url_encode e url_encode_plus para codificar caracteres aplicáveis quando eles aparecem no nome do objeto ou na string de consulta de um URL de solicitação. Exemplo:

- init:
    assign:
        - source_bucket: "my-bucket"
        - file_name: "my-folder/my-file.json"
- list_objects:
    call: googleapis.storage.v1.objects.get
    args:
        bucket: ${source_bucket}
        object: ${text.url_encode(file_name)}
        alt: media
    result: r
- returnStep:
    return: ${r}

Se você não codificar o nome do objeto em URL e o bucket de armazenamento tiver pastas, a solicitação vai falhar. Para mais informações, consulte Como codificar partes do caminho do URL e Considerações sobre nomenclatura do Cloud Storage.

Erros HTTP `429 Too many requests`

Há um número máximo de execuções de fluxo de trabalho ativas que podem ser executadas simultaneamente. Quando essa cota é esgotada, e se o backlog de execução estiver desativado ou se a cota para execuções em backlog for atingida, as novas execuções vão falhar com um código de status HTTP 429 Too many requests.

O backlog de execução permite colocar as execuções de fluxo de trabalho em fila quando a cota de execuções simultâneas é atingida. Por padrão, o backlog de execução é ativado para todas as solicitações (incluindo as acionadas pelo Cloud Tasks), com as seguintes exceções:

Ao criar uma execução usando um conector executions.run ou executions.create em um fluxo de trabalho, o backlog de execução é desativado por padrão. Para configurá-lo, defina explicitamente o campo disableConcurrencyQuotaOverflowBuffering da execução como false.
Para execuções acionadas pelo Pub/Sub, o backlog de execução é desativado e não pode ser configurado.

Para mais informações, consulte Gerenciar o backlog de execução.

Também é possível ativar uma fila do Cloud Tasks para executar fluxos de trabalho filhos em uma taxa definida por você e alcançar uma taxa de execução melhor. Nesse caso, talvez seja necessário desativar explicitamente o backlog de execução.

Erros de permissão da conta de serviço entre projetos

Se você receber um erro PERMISSION_DENIED ao tentar usar uma conta de serviço entre projetos para implantar um fluxo de trabalho, verifique se a restrição booleana iam.disableCrossProjectServiceAccountUsage não está aplicada ao projeto e se você configurou corretamente a conta de serviço. Para mais informações, consulte Implantar um fluxo de trabalho com uma conta de serviço entre projetos.

O nome do recurso precisa estar em conformidade com a RFC 1123

A execução do fluxo de trabalho falha quando um servidor HTTP responde com um código do erro 400. Exemplo:

"description": "must conform to RFC 1123: only lowercase, digits, hyphens,
and periods are allowed, must begin and end with letter or digit, and less
than 64 characters."

Para resolver esse problema, verifique se o nome do recurso segue o padrão de rótulo DNS, conforme definido em RFC 1123, e se, ao atribuir variáveis, você está concatenando strings e expressões corretamente.

Por exemplo, não é possível atribuir uma variável como esta: - string: hello-${world}. Em vez disso, faça isto:

YAML

  - assign_vars:
      assign:
          - string: "hello"
          - string: ${string+" "+"world"}

JSON

  [
    {
      "assign_vars": {
        "assign": [
          {
            "string": "hello"
          },
          {
            "string": "${string+" "+"world"}"
          },
        ]
      }
    }
  ]

Expressões com dois-pontos

No YAML, expressões que contêm dois-pontos podem causar um comportamento inesperado quando os dois-pontos são interpretados como a definição de um mapa. Embora seja possível implantar e executar o fluxo de trabalho, a saída não será a esperada.

Se você criar um fluxo de trabalho usando o console do Google Cloud , ele não poderá ser renderizado visualmente no console do Google Cloud , e talvez você receba um aviso semelhante ao seguinte:

Aviso de criação de fluxo de trabalho

Para resolver esse problema, coloque a expressão YAML entre aspas simples:

Recomendado: '${"a: " +string(a)}'

Não recomendado: ${"a: " +string(a)}

Chaves de mapa que usam caracteres não alfanuméricos

Ao acessar chaves de mapa com caracteres não alfanuméricos (por exemplo, o ponto de exclamação em "special!key": value), é necessário colocar o nome da chave entre aspas. Se o nome da chave não estiver entre aspas, o fluxo de trabalho não poderá ser implantado. Por exemplo, se você tentar implantar o código-fonte a seguir, um token recognition error será gerado:

- init:
    assign:
    - var:
        key:
            "special!key": bar
- returnOutput:
    return: '${"foo" + var.key[special!key]}'

Para resolver isso, use o seguinte código para retornar a saída:

'${"foo" + var.key["special!key"]}'

Várias expressões em uma lista

O uso de várias expressões em uma lista, como o exemplo de intervalo de iteração a seguir, não é um YAML válido:

[${rangeStart}, ${rangeEnd}])

Para resolver esse problema, siga um destes procedimentos:

Coloque a lista dentro de uma expressão:

${[rangeStart, rangeEnd]}
Coloque cada expressão entre aspas simples:

['${rangeStart}', '${rangeEnd}']

O resultado é uma lista de dois valores, como esperado.

Chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês)

Talvez você encontre erros ao usar o Cloud KMS com o Workflows. A tabela a seguir descreve diferentes problemas e como resolvê-los.

Problema	Descrição
A permissão `cloudkms.cryptoKeyVersions.useToEncrypt` foi negada	A chave do Cloud KMS fornecida não existe ou a permissão não está configurada corretamente. Solução: Verifique se a chave do Cloud KMS existe. Liste as chaves de um keyring especificado e verifique o uso delas. Verifique se o agente de serviço do Workflows tem acesso à chave e recebeu o papel `cloudkms.cryptoKeyEncrypterDecrypter`.
A versão da chave não está ativada	A versão da chave do Cloud KMS fornecida foi desativada. Solução: reative a versão da chave do Cloud KMS.
A região do keyring não corresponde ao recurso a ser protegido	A região do keyring do KMS fornecida é diferente da região do fluxo de trabalho. Solução: use um keyring do Cloud KMS e um fluxo de trabalho protegido da mesma região. Eles podem estar em projetos diferentes. Para mais informações, consulte Locais do Cloud KMS e Locais do Workflows.
O limite de cota do Cloud KMS foi excedido	Seu limite de cota para solicitações do Cloud KMS foi atingido. Solução: limite o número de chamadas do Cloud KMS ou aumente o limite da cota. Para mais informações, consulte Cotas do Cloud KMS.

Entidade solicitada não encontrada ao usar o conector do Cloud Run

A execução do fluxo de trabalho falha quando um servidor HTTP responde com um código do erro 404 ao tentar usar o método do conector, googleapis.run.v1.namespaces.jobs.create.

Esse método exige que você especifique o local do endpoint HTTP. Por exemplo, us-central1 ou asia-southeast1. Se você não especificar um local, o endpoint global https://run.googleapis.com será usado. No entanto, esse local aceita apenas métodos de lista.

Para resolver esse problema, especifique um argumento location ao chamar o conector. Para opções de localização da API Cloud Run Admin, consulte endpoints de serviço.

Limites de recurso

Se você encontrar limites de recursos ou um erro como ResourceLimitError, MemoryLimitExceededError ou ResultSizeLimitExceededError, libere memória limpando variáveis. Por exemplo, talvez você queira liberar memória necessária para as etapas seguintes. Ou você pode ter chamadas com resultados que não são importantes e omitir esses resultados.

Recuo YAML

O recuo do YAML é significativo e precisa ter pelo menos dois espaços por nível de recuo. Recuo insuficiente pode causar erros, e um novo nível precisa ter pelo menos dois espaços a partir do início do texto na linha anterior.

Por exemplo, o código a seguir especifica incorretamente um item de lista que contém um mapa com itens stepName e call:

- stepName:
  call: sys.log

Em vez disso, recue a linha seguinte em dois espaços para aninhar call em stepName:

- stepName:
    call: sys.log

Use espaços, em vez de caracteres de tabulação, para recuar as linhas.

A seguir

Problemas conhecidos do Workflows

Resolver problemas Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.