Masalah umum untuk Workflows

Halaman ini mencantumkan masalah umum untuk Workflows.

Anda juga dapat memeriksa masalah yang ada atau membuka masalah baru di issue tracker publik.

Penempatan for langsung setelah try

Menempatkan for langsung setelah try akan menyebabkan error. Misalnya, satu langkah dapat ditempatkan langsung setelah try, seperti ini:

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

Namun, jika Anda memosisikan for setelah try, langkah akan gagal, dan Anda tidak dapat men-deploy alur kerja. Contoh:

- try:
    try:
      for:
        value: v
        range: [1,2]
        steps:
          - log:
              call: sys.log
              args:
                data: ${v}
    retry: ${http.default_retry}

Berikut adalah pesan error-nya:

Could not deploy workflow: failed to build: error in step try: loop step name should not be empty (Code: 3)

Solusinya adalah menambahkan langkah bernama setelah try. Contoh:

- try:
    try:
      steps:
        - loopStep:
            for:
              value: v
              range: [1,2]
              steps:
                - log:
                    call: sys.log
                    args:
                      data: ${v}
    retry: ${http.default_retry}

Peristiwa lebih besar dari ukuran argumen maksimum

Jika menggunakan Workflows sebagai tujuan untuk pemicu Eventarc, peristiwa yang lebih besar daripada ukuran argumen Workflow maksimum akan gagal memicu eksekusi alur kerja. Untuk mengetahui informasi selengkapnya, silakan melihat Kuota dan batas.

HTTP request lost pesan dalam log

Saat menjalankan alur kerja yang memanggil Cloud Build, alur kerja Anda akan gagal dan terdapat pesan HTTP request lost dalam log yang mirip dengan yang berikut ini:

[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

Jika Anda menemukan error ini, coba ubah alur kerja dengan menerapkan kebijakan coba lagi atau melalui penanganan pengecualian yang eksplisit.

Logging panggilan dan metode accessString untuk mengambil data rahasia

Jika level logging panggilan ditetapkan ke log-all-calls saat menggunakan metode helper accessString untuk mengambil data secret, nilai secret tidak akan disamarkan, dan dicetak dalam teks biasa ke log di jsonPayload.succeeded.response.

Pengecualian operasi yang berjalan lama saat menggunakan konektor Cloud Resource Manager

Metode konektor Resource Manager, googleapis.cloudresourcemanager.v3.projects.patch, tidak menampilkan nama operasi yang berjalan lama (LRO). Bahkan untuk permintaan yang berhasil, pengecualian yang serupa dengan berikut mungkin akan diajukan:

exception: "{"message":"Long-running operation returned unexpected response.",
"operation":{"done":true,"response":{"@type":"type.googleapis.com/google.cloud.resourcemanager.v3.Project",
...
"tags":["ResponseTypeError"]}"

Untuk menghindari error polling LRO, tetapkan parameter konektor skip_polling ke true agar panggilan pemanggilan konektor tidak memblokir jika permintaan awal berhasil. Permintaan yang berhasil akan menampilkan "done":true; jika tidak, untuk menangkap pengecualian apa pun, gunakan struktur try/except. Untuk mengetahui informasi selengkapnya, lihat Referensi konektor.

Langkah selanjutnya

Pelajari strategi yang bermanfaat saat memecahkan masalah.