šŸš€ Pengujian untuk Transaksi Gagal: Checklist Builder untuk STONfi

Kebanyakan tutorial swap berhenti pada happy path. Jalankan hanya itu saja, dan Anda baru menguji mungkin 60% dari hal-hal yang benar-benar dilempar produksi—eksekusi TON yang asinkron dan berbasis pesan menghasilkan bentuk kegagalan yang tidak benar-benar dipersiapkan oleh insting EVM Anda.

🧭 Kegagalan yang Memang Terjadi

Refund slippage adalah perlindungan yang bekerja sesuai maksud, bukan bug—uji nilai yang ketat, longgar, dan nilai batas, bukan cuma satu nilai "default" yang masuk akal. Cross-swap yang dirutekan lewat token perantara tidak bisa sepenuhnya melakukan refund jika gagal di tengah-hop, karena transaksi multi-kontrak di TON tidak bersifat atomik—pengguna akhirnya memegang token perantara, bukan aset aslinya kembali. Satu isu GitHub nyata yang terdokumentasi menunjukkan swap tersiar bersih, lalu gagal on-chain dengan exit_code 11—bukti bahwa "panggilan SDK tidak melempar error" tidak pernah sama dengan "benar-benar berhasil." Sebagian kegagalan yang signifikan bahkan tidak pernah menyentuh blok: TonConnect menolak alamat yang tidak valid, window validitas yang kedaluwarsa, dan pembatalan oleh pengguna—yang terakhir ini seharusnya tidak pernah mendarat diam-diam di log error Anda dengan disamarkan sebagai bug.

āœ… Susun Matriks Pengujian Berdasarkan Ini

Pastikan hasil token perantara untuk kegagalan cross-swap parsial, verifikasi exit code on-chain setelah pengiriman, bukan hanya mempercayai panggilan SDK, pisahkan pelacakan penolakan dompet dari kegagalan on-chain yang benar, dan bangun ulang setiap transaksi dari kuotasi terbaru, bukan dari yang tersimpan/ketinggalan.

šŸ Uji bagaimana STONfi benar-benar gagal, bukan bagaimana swap gagal secara umum—dan celah antara staging dengan tiket dukungan nyata pertama Anda akan menyempit dengan cepat.

$XRP