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 辅助方法检索机密数据时设置为 log-all-calls，则机密值不会被遮盖，而是以纯文本形式打印到 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 结构。如需了解详情，请参阅连接器参考文档。

向 Google Kubernetes Engine (GKE) 发出的 HTTP 请求

每个 GKE 集群都有一个用于处理 Kubernetes API 请求的控制平面。控制平面有两种用于访问集群的端点：基于 DNS 的端点和基于 IP 的端点。如需了解详情，请参阅控制平面访问。

Workflows 不再支持向 GKE 集群控制平面的 基于 IP 的端点发送 HTTP 请求。如需详细了解此次弃用的范围和影响，请参阅服务公告。

为确保工作流按预期运行，您必须访问基于 DNS 的端点。如需访问基于 DNS 的端点，我们建议您在工作流中使用 Kubernetes API 连接器。如需了解详情，请参阅使用连接器访问 Kubernetes API 对象。

后续步骤

了解有助于排查问题的策略。