このページは Cloud Translation API によって翻訳されました。

Workflows の既知の問題

このページには、Workflows の既知の問題が記載されています。

また、公開 Issue Tracker で既存の問題の確認や、新しい問題の報告を行うことができます。

`try` の直後への `for` の配置

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}

引数の最大サイズを超えるイベント

Eventarc トリガーの宛先として Workflows を使用している場合、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 リクエストを処理するコントロールプレーンがあります。コントロールプレーンには、クラスタアクセス用の 2 種類のエンドポイント（DNS ベースのエンドポイントと IP ベースのエンドポイント）があります。詳細については、コントロールプレーンアクセスをご覧ください。

Workflows は、GKE クラスタコントロールプレーンの IP ベースのエンドポイントへの HTTP リクエストをサポートしなくなりました。このサポート終了の範囲と影響の詳細については、サービスに関するお知らせをご覧ください。

ワークフローが想定どおりに機能することを確認するには、DNS ベースのエンドポイントにアクセスする必要があります。DNS ベースのエンドポイントにアクセスするには、ワークフローで Kubernetes API コネクタを使用することをおすすめします。詳細については、コネクタを使用して Kubernetes API オブジェクトにアクセスするをご覧ください。

次のステップ

問題のトラブルシューティングに役立つ戦略を確認する。