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 exemplos do console Google Cloud e da CLI gcloud a seguir.

Console

Quando ocorre um erro de implantação, o Workflows mostra uma mensagem de erro em um banner na página Editar fluxo de trabalho: Erro de implantação 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

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

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

ou

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 IAM no momento da criação. Para resolver esse problema, conceda à conta de serviço um ou mais papéis do IAM que contenham as permissões mínimas necessárias para gerenciar o fluxo de trabalho. Por exemplo, se você quiser 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 Google Cloud .

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 de objetos em URL para serem seguros. Você pode 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 por 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 é atingida e se o acúmulo de execuções está desativado ou se a cota de execuções em espera é atingida, todas as novas execuções falham com um código de status HTTP 429 Too many requests.

Com o acúmulo de execuções, é possível colocar em fila as execuções de fluxo de trabalho quando a cota de execuções simultâneas é atingida. Por padrão, o acúmulo de execuções está 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 acúmulo de execuções fica desativado por padrão. É possível configurar isso definindo explicitamente o campo disableConcurrencyQuotaOverflowBuffering da execução como false.
  • Para execuções acionadas pelo Pub/Sub, o acúmulo de execuções é desativado e não pode ser configurado.

Para mais informações, consulte Gerenciar o acúmulo de execuções.

Você também pode 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 acúmulo de execuções.

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 é aplicada ao seu 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 de 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 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 assim: - 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"}"