“Transaksi sudah selesai, tapi halamannya belum berubah?”—kalimat ini kalau dipasang di backend dompet atau bursa, biasanya bukan masalah pengguna; melainkan sistem yang gagal menangkap event.

HTTP API untuk @Dusk menempatkan langganan event kontrak pada jalur /on/contracts:<contract_id>/<method>. Langganan dan pembatalannya masing-masing menggunakan GET dan DELETE, dan semuanya perlu bergantung pada Rusk-Session-Id untuk mempertahankan sesi. Tampak seperti detail API, tetapi menurut saya sebenarnya ia sedang mengingatkan satu hal: notifikasi real-time itu sendiri bukanlah buku besar.

Saat koneksi normal, dompet memperbarui saldo berdasarkan event, sedangkan bursa mendorong pengumpulan atau status pesanan lewat event. Namun setelah koneksi terputus, session hanya bisa membantu mengembalikan hubungan langganan, tidak bisa membuktikan bahwa tidak ada sesuatu yang terlewat di tengah. Bagian yang terlewat, tetap harus diverifikasi ulang dari kondisi blok, transaksi, dan status kontraknya.

Saya membayangkan skenario yang konkret. Transaksi transfer DUSK milik pengguna sudah di-chain, tetapi koneksi listener bursa kebetulan terputus selama beberapa menit. Catatan di chain tidak ada masalah, saldo tidak ter-update. Saat pengguna mengirim lagi, di backend bisa muncul dua catatan yang sama-sama “menunggu diproses” sekaligus. CS yang melihat mengatakan “belum masuk”, sedangkan tim operasional menghadapi kompensasi event plus rekonsiliasi manual.

Ini membuat saya menambahkan lapisan tuntutan pada interface event untuk @Dusk . Menuliskan endpoint langganan di dokumentasi baru langkah pertama; yang benar-benar menentukan kualitas integrasi adalah apakah dompet dan bursa bisa memulihkan konteks setelah reconnect berdasarkan session, lalu mengisi celahnya dengan status di chain. $DUSK harus menampung perputaran aset yang nyata, event real-time bertugas mengingatkan, dan pada akhirnya status harus punya jalur lain yang dapat diverifikasi ulang. #dusk