Para acessar os resultados da execução de um fluxo de trabalho, clique no nome dele
para acessar a página Detalhes do fluxo de trabalho.
Para detalhes sobre uma execução específica, na guia Executions, clique no ID da execução na lista para acessar a página Execution details.
Na guia Resumo, cada execução tem as seguintes informações:
ID da execução: o identificador exclusivo da execução do fluxo de trabalho.
Estado de execução: indica o estado final do fluxo de trabalho, incluindo a
etapa atual ou final do fluxo de trabalho.
Execução criada: quando a execução foi iniciada.
Início da execução: quando a execução começou a ser executada e a executar etapas.
Fim da execução: quando a execução foi finalizada.
Duração da execução: tempo total decorrido. Isso pode ser uma indicação de
erros de rede ou problemas de conectividade.
Nome do fluxo de trabalho: o nome do fluxo de trabalho.
Revisão do fluxo de trabalho: a revisão atual no momento da execução.
Nível de registro de chamadas: o nível de registro de chamadas aplicado durante a
execução. Para mais informações, consulte
Registro de chamadas.
Entrada: os argumentos de ambiente de execução transmitidos para o fluxo de trabalho, se houver.
Saída: a saída do fluxo de trabalho. Se a execução falhou, inclui a
exceção que levou à falha. Neste documento, consulte
Mapas de erros de execução.
Para conferir o histórico de execução do fluxo de trabalho como uma lista de entradas de etapas, clique na guia Etapas. Para mais informações, consulte
Consultar o histórico das etapas de execução.
Para conferir os registros de uma execução de fluxo de trabalho, clique na guia Registros.
Para filtrar os registros de execução, use o campo Filtro na parte
superior da tabela. Por exemplo, para exibir apenas tentativas de execução malsucedidas, insira
failed no campo de texto do filtro.
gcloud
Para ver uma lista completa das execuções de um fluxo de trabalho, digite o seguinte
comando:
gcloudworkflowsexecutionslistWORKFLOW_NAME
Substitua WORKFLOW_NAME pelo nome do fluxo de trabalho.
Copie o ID de execução do seu interesse.
Para ver os registros de execução de um fluxo de trabalho, digite o seguinte comando:
argument: os argumentos de ambiente de execução transmitidos para o fluxo de trabalho, se houver
endTime: quando a execução foi finalizada
error: a mensagem de erro gerada como parte da exceção que
resultou na falha da execução
name: o nome completo da execução, incluindo o nome do
projeto, o local do fluxo de trabalho, o nome do fluxo de trabalho e o
ID da execução
startTime: quando a execução começou
state: indica o estado final do fluxo de trabalho
status: a etapa atual ou final do fluxo de trabalho da execução
workflowRevisionID: a revisão atual no momento da execução
Mapas de erros de execução
Quando um fluxo de trabalho gera um erro durante a execução que não é capturado em um
bloco try/except, a
execução falha e um mapa de erros (um dicionário JSON) que descreve o erro é
retornado.
Os erros gerados durante a execução do fluxo de trabalho contêm tags para ajudar a identificar
o que causou o erro. Por exemplo, o erro retornado de um conector pode ter duas
chaves (tags e message) semelhantes a estas:
{'tags': ['SystemError'], 'message': 'an error has occurred'}
É possível incluir mais de uma tag. Para verificar uma tag específica, use uma expressão. Exemplo:
${'SystemError' in e.tags}
Acessar dados de erro retornados como uma string
Alguns conectores e APIs HTTP serializam erros como strings antes de retornar
os erros. É possível usar funções de biblioteca padrão para restaurar um payload ao
erro original. Por exemplo, para converter uma string de erro em um mapa, use
as funções json.decode
e text.encode:
json.decode(text.encode(ERROR_FROM_API))
Tags de erro
A tabela a seguir descreve o significado de diferentes tags de erro.
Tag
Descrição
AuthError
Surge ao gerar credenciais para uma solicitação HTTP.
ConnectionError
Gerado quando uma conexão é estabelecida com o endpoint,
mas há um problema com a conexão durante a transferência de dados. A
conexão é encerrada antes do recebimento de uma resposta completa, e uma mensagem
pode não ter sido entregue ao endpoint. As novas tentativas podem não ser
idempotentes.
ConnectionFailedError
Surge quando uma conexão não é estabelecida com o endpoint da API. Por
exemplo, devido a um nome de domínio incorreto, problemas de resolução de DNS ou outros
problemas de rede. As novas tentativas são idempotentes.
Surge quando algum limite de recurso é esgotado. Quando gerado internamente,
esse tipo de erro não pode ser capturado e causa falha de execução
imediata.
ResponseTypeError
É gerado quando uma operação de longa duração retorna uma resposta do tipo
errado.
SystemError
Surge quando o intérprete encontra um erro interno.
TimeoutError
Surge quando uma função do sistema atinge o tempo limite no nível do sistema.
TypeError
Surge quando uma operação ou função é aplicada a um objeto de
tipo incompatível. O valor associado é uma string que fornece detalhes sobre a
incompatibilidade de tipos.
UnhandledBranchError
É gerada quando uma ou mais ramificações ou iterações encontram um
erro de execução não tratado até um
número máximo.
ValueError
Surge quando uma operação ou função recebe um argumento que tem o
tipo correto, mas um valor incorreto, e a situação não é descrita
por uma exceção mais precisa, como um IndexError.
ZeroDivisionError
Surge quando o segundo argumento de uma divisão ou operação de módulo é
zero. O valor associado é uma string que indica o tipo
dos operandos e a operação.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-18 UTC."],[],[],null,["# Access workflow execution results\n\nAfter you [execute a workflow](/workflows/docs/executing-workflow), you can\naccess workflow execution results in the Google Cloud console or by using the\nGoogle Cloud CLI. \n\n### Console\n\n1. In the Google Cloud console, go to the **Workflows** page.\n\n\n [Go to Workflows](https://console.cloud.google.com/workflows)\n\n \u003cbr /\u003e\n\n2. To access a workflow's execution results, click the workflow's name to go\n to its **Workflow details** page.\n\n3. For details about a particular execution, on the **Executions** tab, click\n the execution ID in the list to go to its **Execution details** page.\n\n | **Note:** To access the **Execution details** page, you must have a role that contains the `workflows.workflows.get`, `workflows.executions.get`, and `workflows.stepEntries.list` permissions. For more information, see [Workflows roles and\n | permissions](/workflows/docs/access-control) and [Manage access](/iam/docs/granting-changing-revoking-access).\n4. On the **Summary** tab, each execution has the following information:\n\n - **Execution ID**: the unique identifier of the workflow execution.\n - **Execution state**: indicates the workflow's end state, including the current or final workflow step.\n - **Execution created**: when the execution was initiated.\n - **Execution start**: when the execution began running and executing steps.\n - **Execution end**: when the execution ended.\n - **Execution duration**: total time elapsed. This can be an indication of network errors or connectivity problems.\n - **Workflow name**: the workflow name.\n - **Workflow revision**: the current revision at the time of execution.\n - **Call log level** : the level of call logging applied during the execution. For more information, see [Call logging](/workflows/docs/log-workflow#call_logging).\n - **Input**: the runtime arguments passed to the workflow, if any.\n - **Output** : the workflow's output. If the execution failed, includes the exception that led to the execution's failure. In this document, see [Execution error maps](#execution_errors).\n5. To view the workflow execution history as a list of step entries, click the\n **Steps** tab. For more information, see\n [View history of execution steps](/workflows/docs/debug-steps).\n\n6. To view the logs for a workflow execution, click the **Logs** tab.\n\n7. To filter the execution logs, use the **Filter** field at the top of the\n table. For example, to display only failed execution attempts, enter\n `failed` in the filter's text field.\n\n### gcloud\n\n1. To see a full list of a workflow's executions, enter the following\n command:\n\n gcloud workflows executions list \u003cvar translate=\"no\"\u003eWORKFLOW_NAME\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eWORKFLOW_NAME\u003c/var\u003e with your workflow's name.\n Copy the execution ID of the execution you're interested in.\n2. To view a workflow's execution logs, enter the following command:\n\n gcloud workflows executions describe \\\n --workflow=\u003cvar translate=\"no\"\u003eWORKFLOW_NAME\u003c/var\u003e \\\n \u003cvar translate=\"no\"\u003eEXECUTION_ID\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eWORKFLOW_NAME\u003c/var\u003e: the workflow's name\n - \u003cvar translate=\"no\"\u003eEXECUTION_ID\u003c/var\u003e: the execution's unique ID\n\n This command returns output similar to the following: \n\n ```bash\n argument: 'null'\n endTime: '2022-07-19T12:40:07.070039707Z'\n error:\n context: |-\n The argument of 'in' must be a dict or an array; got: null\n in step \"checkSearchTermInInput\", routine \"main\", line: 12\n payload: \"{\"message\":\"The argument of 'in' must be a dict or an array; got: null\"\n\n ,\"tags\":[\"TypeError\"]}\"\n stackTrace:\n elements:\n - position:\n column: '26'\n length: '24'\n line: '12'\n routine: main\n step: checkSearchTermInInput\n name: projects/1051295516635/locations/us-central1/workflows/myFirstWorkflow/executions/17ffc89c-0a27-4d2f-8356-e681d949a3d3\n startTime: '2022-07-19T12:40:07.024823663Z'\n state: FAILED\n status:\n currentSteps:\n - routine: main\n step: checkSearchTermInInput\n workflowRevisionId: 000001-ac2\n ```\n The output contains the following information:\n\n \u003cbr /\u003e\n\n - `argument`: the runtime arguments passed to the workflow, if any\n - `endTime`: when the execution ended\n - `error`: the error message thrown as a part of the exception that resulted in the execution's failure\n - `name`: the full name of the execution, including the name of the project, the location of the workflow, the name of the workflow, and the execution ID\n - `startTime`: when the execution began\n - `state`: indicates the workflow's end state\n - `status`: the current or final workflow step of the execution\n - `workflowRevisionID`: the current revision at the time of the execution\n\n### Execution error maps\n\nWhen a workflow throws an error during execution that isn't caught in a\n[`try/except` block](/workflows/docs/reference/syntax/catching-errors), the\nexecution fails, and an error map (a JSON dictionary) describing the error is\nreturned.\n\nErrors thrown during workflow execution contain tags to help you identify what\ncaused the error. For example, the error returned from a connector can have two\nkeys (`tags` and `message`) similar to the following:\n\n`{'tags': ['SystemError'], 'message': 'an error has occurred'}`\n\nThere can be more than one tag. To check for a specific tag, you can use an\n[expression](/workflows/docs/reference/syntax/expressions). For example:\n\n`${'SystemError' in e.tags}`\n\n### Access error data returned as a string\n\nSome connectors and HTTP APIs will serialize errors as strings before returning\nthe errors. You can use standard library functions to restore a payload to the\noriginal error. For example, to convert an error string to a map, you can use\nthe [`json.decode`](/workflows/docs/reference/stdlib/json/decode)\nand [`text.encode`](/workflows/docs/reference/stdlib/text/encode) functions: \n\n```bash\njson.decode(text.encode(ERROR_FROM_API))\n```\n\n### Error tags\n\nThe following table describes the meaning of different error tags.\n\nYou can also [raise custom errors](/workflows/docs/reference/syntax/raising-errors)\nusing the `raise` syntax.\n\nWhat's next\n-----------\n\n- [Debugging overview](/workflows/docs/debug)\n- [Known issues for Workflows](/workflows/docs/issues)\n- [Send execution logs to Cloud Logging](/workflows/docs/log-workflow)\n- [Troubleshoot issues](/workflows/docs/troubleshooting)"]]