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 under
jsonPayload.succeeded.response
.
What's next
Learn strategies helpful when troubleshooting issues.