Workflows 的已知问题

本页面列出了 Workflows 的已知问题。

您还可以在公开问题跟踪器中检查现有问题或添加新问题。

将 for 放置在 try 之后

直接在 try 后面放置 for 会导致错误。例如，可以将单个步骤直接放在 try 之后，如下所示：

- try:
    try:
      call: sys.log
      args:
        data: works
    retry: ${http.default_retry}

但是，如果将 for 放在 try 之后，则步骤会失败，并且您无法部署工作流。例如：

- try:
    try:
      for:
        value: v
        range: [1,2]
        steps:
          - log:
              call: sys.log
              args:
                data: ${v}
    retry: ${http.default_retry}

错误消息如下所示：

Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)

解决方法是在 try 之后添加一个命名的步骤。例如：

- try:
    try:
      steps:
        - loopStep:
            for:
              value: v
              range: [1,2]
              steps:
                - log:
                    call: sys.log
                    args:
                      data: ${v}
    retry: ${http.default_retry}

事件超出参数大小上限

如果将 Workflows 用作 Eventarc 触发器的目标，则超出 Workflows 参数大小上限的事件将无法触发工作流执行。如需了解详情，请参阅配额和限制。

日志中有 HTTP request lost 条消息

在执行调用 Cloud Build 的工作流时，您的工作流会失败，并且日志中出现类似于以下内容的 HTTP request lost 消息：

[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

如果遇到此错误，请尝试通过实现重试政策或通过明确的异常处理来修改工作流。

用于检索 Secret 数据的调用日志记录和 accessString 方法

如果在使用 accessString 辅助方法检索 Secret 数据时将通话记录级别设置为 log-all-calls，则 Secret 值不会被隐去，并以纯文本形式输出到 jsonPayload.succeeded.response 中的日志。

使用 Cloud Resource Manager 连接器时出现长时间运行的操作异常

Resource Manager 连接器方法 googleapis.cloudresourcemanager.v3.projects.patch 不会返回长时间运行的操作 (LRO) 名称。即使请求成功，也可能引发类似于以下内容的异常：

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

为避免 LRO 轮询错误，请将 skip_polling 连接器参数设置为 true，以便在初始请求成功时，连接器调用不会阻塞。如果请求成功，则返回 "done":true；否则，要捕获任何异常，请使用 try/except 结构。如需了解详情，请参阅连接器参考文档。

后续步骤

学习有助于排查问题的策略。