「取引は完了したのに、ページがまだ変わっていない？」——この言葉をウォレットや取引所の管理画面に置いたところで、通常それはユーザーの問題ではなく、システムがイベントを取り逃しているだけです。

@Dusk の HTTP API では、コントラクトのイベント購読を /on/contracts:<contract_id>/<method> というパスに置きます。購読と購読解除はそれぞれ GET、DELETE で行い、さらに Rusk-Session-Id でセッションを維持する必要があります。インターフェースの細部のように見えて、実は一つの事実を思い出させてくれています。リアルタイム通知そのものは台帳ではない、ということです。

接続が正常なとき、ウォレットはイベントで残高を更新し、取引所はイベントでアグリゲーションや注文ステータスを進めます。しかし接続が切れた後、session でできるのは購読関係の復元までで、その間に何かを取りこぼしていないことを証明はできません。取りこぼした分は、ブロック、取引、コントラクトの状態に戻って照合し直すしかありません。

具体的なシナリオを一つ思い浮かべてみます。ユーザーの DUSK の送金はすでにチェーンに上がっていますが、取引所のリスニング接続がちょうど数分間途切れたとします。チェーン上の記録に問題はなく、残高も更新されません。ユーザーがもう一度送信すると、バックエンドでは同時に二つの「処理待ち」記録が出てしまう可能性があります。コールセンターが見るのは「入金がない」、運用チームが向き合うのは「イベント補償」と「人手による照合」です。

これにより、@Dusk のイベント API には一段階追加の要求を感じるようになりました。ドキュメントが購読の入口を示すのは第一歩にすぎず、統合品質を最終的に決めるのは、ウォレットと取引所が再接続後に session でコンテキストを取り戻し、さらにチェーン上の状態で欠けを埋められるかどうかです。$DUSK が現実の資産の流れを担うのなら、リアルタイムのイベントは注意喚起の役割を果たし、最終状態は別の再確認可能なルートを持つ必要があります。#dusk