“交易已经完成，页面还没变？”——这话放到钱包或交易所后台，通常不是用户的问题，是系统漏接了事件。
@Dusk_Foundation 的 HTTP API 把合约事件订阅放在 /on/contracts:<contract_id>/<method> 这条路径。订阅和取消订阅分别用 GET、DELETE，还得靠 Rusk-Session-Id 维持会话。看着像接口细节，我觉得它其实在提醒一件事：实时通知本身不是账本。
连接正常时，钱包靠事件更新余额，交易所靠事件推进归集或订单状态。但连接断了以后，session 只能帮你找回订阅关系，不能证明中间没漏掉东西。漏掉的那段，还是得回到区块、交易和合约状态里重新对。
我脑补个具体场景。用户的 DUSK 转账已经上链了，交易所的监听连接刚好断了几分钟。链上记录没问题，余额没更新。用户再提交一次，后台可能同时出现两笔待处理记录。客服看到的是“不到账”，运营团队面对的是事件补偿加人工对账。
这让我对 @Dusk_Foundation 的事件接口多了一层要求。文档把订阅入口写出来只是第一步，真正决定集成质量的，是钱包和交易所能不能在重连后按 session 找回上下文，再用链上状态把缺口补上。$DUSK 要承载真实资产流转，实时事件负责提醒，最终状态必须有另一条可复核的路。#dusk
@Dusk_Foundation 的 HTTP API 把合约事件订阅放在 /on/contracts:<contract_id>/<method> 这条路径。订阅和取消订阅分别用 GET、DELETE，还得靠 Rusk-Session-Id 维持会话。看着像接口细节，我觉得它其实在提醒一件事：实时通知本身不是账本。
连接正常时，钱包靠事件更新余额，交易所靠事件推进归集或订单状态。但连接断了以后，session 只能帮你找回订阅关系，不能证明中间没漏掉东西。漏掉的那段，还是得回到区块、交易和合约状态里重新对。
我脑补个具体场景。用户的 DUSK 转账已经上链了，交易所的监听连接刚好断了几分钟。链上记录没问题，余额没更新。用户再提交一次，后台可能同时出现两笔待处理记录。客服看到的是“不到账”，运营团队面对的是事件补偿加人工对账。
这让我对 @Dusk_Foundation 的事件接口多了一层要求。文档把订阅入口写出来只是第一步，真正决定集成质量的，是钱包和交易所能不能在重连后按 session 找回上下文，再用链上状态把缺口补上。$DUSK 要承载真实资产流转，实时事件负责提醒，最终状态必须有另一条可复核的路。#dusk