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 under jsonPayload.succeeded.response.

What's next

Learn strategies helpful when troubleshooting issues.