このページには、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
構造を使用します。詳しくは、コネクタのリファレンスをご覧ください。
次のステップ
問題のトラブルシューティングに役立つ戦略を確認する。