Workflows の既知の問題

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

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

try の直後への for の配置

try の直後に for を配置すると、エラーが発生します。たとえば、次のように try の直後に 1 つのステップを配置できます。

- try:
    try:
      call: sys.log
      args:
        data: works
    retry: ${http.default_retry}

ただし、fortry の後に配置した場合、ステップは失敗し、ワークフローをデプロイできません。例:

- 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 構造を使用します。詳しくは、コネクタのリファレンスをご覧ください。

次のステップ

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