Known issues for Workflows

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:

exception: "{"message":"Long-running operation returned unexpected response.",
"operation":{"done":true,"response":{"@type":"type.googleapis.com/google.cloud.resourcemanager.v3.Project",
...
"tags":["ResponseTypeError"]}"

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.

What's next

Learn strategies helpful when troubleshooting issues.