Workflows の既知の問題

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

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

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

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

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

次のステップ

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