This page lists known issues for Workflows.
You can also check for existing issues or open new issues in the public issue trackers .
Placement of for
directly after try
Placing for
directly after try
causes an error. For example, a single step
can be placed directly after try
, like this:
- try : try : call : sys.log args : data : works retry : ${http.default_retry}
However, if you position for
after the try
, the step fails, and you cannot
deploy the workflow. For example:
- try : try : for : value : v range : [ 1 , 2 ] steps : - log : call : sys.log args : data : ${v} retry : ${http.default_retry}
The error message is as follows:
Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)
The workaround is to add a named step after the try
. For example:
- try : try : steps : - loopStep : for : value : v range : [ 1 , 2 ] steps : - log : call : sys.log args : data : ${v} retry : ${http.default_retry}
Events larger than the maximum arguments size
If using Workflows as a destination for an Eventarc trigger, events larger than the maximum Workflows arguments size will fail to trigger workflow executions. For more information, see Quotas and limits .
HTTP request lost
message in logs
When executing a workflow that calls Cloud Build, your workflow fails and
there is an HTTP request lost
message in the logs similar to the following:
[ 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
If you encounter this error, try modifying your workflow by implementing either a retry policy or through explicit exception handling .
Call logging and accessString
method to retrieve secret data
If the call logging level
is set to log-all-calls
when using the accessString
helper method to retrieve secret data
,
the secret value is not redacted, and is printed in plain text to the logs in jsonPayload.succeeded.response
.
Long-running operation exception when using Cloud Resource Manager connector
The Resource Manager connector method, googleapis.cloudresourcemanager.v3.projects.patch
,
doesn't return a long-running operation (LRO) name. Even for a successful
request, an exception similar to the following might be raised:
excep t io n : "{" message ":" Lo n g - ru nn i n g opera t io n re turne d u ne xpec te d respo nse . ", " opera t io n ":{" do ne ":true," respo nse ":{" @ t ype ":" t ype.googleapis.com/google.cloud.resourcema na ger.v 3. Projec t ", ... " ta gs ":[" Respo nse TypeError "]}"
To avoid an LRO polling error,
set the skip_polling
connector parameter to true
so that the connector
invocation call is non-blocking if the initial request succeeds. A successful
request returns "done":true
; otherwise, to catch any exceptions use a try/except
structure
.
For more information, see the Connectors reference
.
HTTP requests to Google Kubernetes Engine (GKE)
Every GKE cluster has a control plane that handles Kubernetes API requests. The control plane has two kinds of endpoints for cluster access: DNS-based endpoints and IP-based endpoints . For more information, see Control plane access .
Workflows no longer supports HTTP requests to the IP-based endpoints of GKE cluster control planes. For more information about the scope and impact of this deprecation, see the service announcement .
To ensure that your workflow functions as expected, you must access DNS-based endpoints . To access the DNS-based endpoints, we recommend that you use the Kubernetes API connector in a workflow. For more information, see Access Kubernetes API objects using a connector .
What's next
Learn strategies helpful when troubleshooting issues .
