This page shows you how to resolve issues that you might encounter when using Workflows.
For more information, refer to monitoring and debugging Workflows.
Deployment errors
When a workflow is deployed, Workflows checks that the source code is free from errors and matches the language syntax. Workflows returns an error if one is found. The most common types of deployment errors are:
- Referencing an undefined variable, step, or subworkflow
- Incorrect syntax
- Incorrect indentation
- Missing or extraneous
{,},",-, or:
For example, the following source code throws a deployment error because the
return statement references an undefined variable, varC:
- step1: assign: - varA: "Hello" - varB: "World" - step2: return: ${varC + varB}
This incorrect source code is used in the following Google Cloud console and gcloud CLI examples.
Console
When a deployment error occurs, Workflows displays the error
message in a banner on the Edit workflow page:
The error message flags the problem in the source code, specifying the origin
of the error when possible:
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
When you run the gcloud workflows deploy command,
Workflows returns an error message to the command line if the
deployment fails. The error message flags the problem in the source code,
specifying the origin of the error when possible:
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
To resolve the issue, edit the workflow's source code. In this case, refer to
varA instead of varC.
HTTP 403 service account permission errors
Your workflow execution fails when an HTTP server responds with an error code
of 403. For example:
Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-developer.gserviceaccount.comcompute@ (or it may not exist).
or
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).
Every workflow is associated with an IAM service account at the
time the workflow is created. To resolve this issue, you must grant the service
account one or more IAM roles that contain the minimum
permissions required to manage your workflow. For example, if you want to let
your workflow send logs to Cloud Logging, make sure the service account
executing the workflow has been granted a role that includes the
logging.logEntries.create permission. For more information, see
Grant a workflow permission to access Google Cloud resources.
HTTP 404 No such object or Not found errors
When using the
Cloud Storage connector,
your workflow execution fails when an HTTP server responds with an error code of
404. For example:
HTTP server responded with error code 404 in step "read_input_file", routine "main", line: 13 { "body": "Not Found", "code": 404, ... }
You should URL-encode object names to be path safe. You can use the
url_encode and
url_encode_plus
functions to encode applicable characters when they appear in either the object
name or query string of a request URL. For example:
- init: assign: - source_bucket: