Workflows 的已知问题

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

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

for 放置在 try 的直接后面

for 直接放置在 try 后面会导致错误。例如,单个步骤可以直接放置在 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

如果遇到此错误,请尝试修改工作流程,方法是执行 重试政策或通过明确的 异常处理

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

如果在使用 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 结构。 有关详情,请参阅 连接器参考

后续步骤

了解在排查问题时很有帮助的策略。