Perilaku yang tidak terduga, batasan operasional, dan solusi yang tersedia dapat memengaruhi eksekusi dan konektor Alur Kerja Anda. Anda juga dapat memeriksa masalah yang ada atau membuka masalah baru di issue tracker publik.
Penempatan for langsung setelah try
Menempatkan for tepat 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 menempatkan 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}
Pesan errornya adalah sebagai berikut:
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 yang lebih besar dari ukuran argumen maksimum
Jika menggunakan Workflows sebagai tujuan pemicu Eventarc, peristiwa yang lebih besar dari ukuran argumen Workflows maksimum akan gagal memicu eksekusi alur kerja. Untuk mengetahui informasi selengkapnya, baca Kuota dan batas.
Pesan HTTP request lost di log
Saat menjalankan alur kerja yang memanggil Cloud Build, alur kerja Anda gagal dan
ada pesan HTTP request lost di log yang mirip dengan 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 mengalami error ini, coba ubah alur kerja dengan menerapkan kebijakan coba lagi atau melalui penanganan pengecualian eksplisit.
Logging panggilan dan metode accessString untuk mengambil data rahasia
Jika
tingkat logging panggilan disetel ke
log-all-calls saat
menggunakan metode helper accessString untuk mengambil data rahasia,
nilai rahasia 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). Meskipun permintaan berhasil, pengecualian yang mirip dengan berikut ini mungkin terjadi:
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 sehingga 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.
Permintaan HTTP ke Google Kubernetes Engine (GKE)
Setiap cluster GKE memiliki bidang kontrol yang menangani permintaan Kubernetes API. Bidang kontrol memiliki dua jenis endpoint untuk akses cluster: endpoint berbasis DNS dan endpoint berbasis IP. Untuk mengetahui informasi selengkapnya, lihat Akses bidang kontrol.
Workflows tidak lagi mendukung permintaan HTTP ke endpoint berbasis IP dari bidang kontrol cluster GKE. Untuk mengetahui informasi selengkapnya tentang cakupan dan dampak penghentian penggunaan ini, lihat pengumuman layanan.
Untuk memastikan alur kerja Anda berfungsi seperti yang diharapkan, Anda harus mengakses endpoint berbasis DNS. Untuk mengakses endpoint berbasis DNS, sebaiknya gunakan konektor Kubernetes API dalam alur kerja. Untuk mengetahui informasi selengkapnya, lihat Mengakses objek Kubernetes API menggunakan konektor.
Langkah berikutnya
Pelajari strategi yang berguna saat memecahkan masalah.