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 連接器時發生長時間執行的作業例外狀況

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 物件。

後續步驟

瞭解有助於排解問題的策略。