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

如果遇到此錯誤，請嘗試透過實作重試政策或明確的例外狀況處理，修改工作流程。

呼叫記錄和 accessString 方法，以便擷取機密資料

如果使用 accessString 輔助方法擷取機密資料時，呼叫記錄等級設為 log-all-calls，則系統不會遮蓋機密值，而是以純文字形式在 jsonPayload.succeeded.response 中的記錄中列印。

使用 Cloud 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 為基礎的端點。如要進一步瞭解範圍和影響，請參閱服務公告。

最佳做法是建議您在工作流程中使用 Kubernetes API 連接器，而非直接發出 HTTP 呼叫。詳情請參閱「使用連接器存取 Kubernetes API 物件」一文。

後續步驟

瞭解排解問題時實用的策略。