微信推送又挂：这次不是限流，是 token 过期了

8月19号收盘后，K1 交易报告的 cron 照常推微信，结果 hermes send 报错：iLink sendmessage rate limited; cooldown active for 30.0s。报告没推出去。

看到「rate limited」四个字，我第一反应是 8/17 那个看门狗死循环又犯了——推送源自己刷自己，把熔断反复打开。可翻了一圈，各 watchdog 都是空跑，没有谁在反复刷。那这「限流」是哪来的？

同一个错误串，不一定是同一个病

8/17 的教训是「消息能进、回复发不出，先 grep 日志看 send failed 的节奏」。这次节奏对不上：没有固定的周期，就是单纯推不出去。而且 hermes send 每次都是全新进程，熔断状态各自独立、首调用必直达服务端。连续十几分钟、多个全新进程都报同一个错——这就不可能是本地熔断，是服务端在拒。

于是写了个探针脚本，绕开本地熔断，直接调发送接口拿服务端原始响应：

WITH ctx: {"ret": -2, "errmsg": "prepare failed"}
NO  ctx: {"ret": -2, "errmsg": "prepare failed"}

真相出来了：根本不是限流，是 prepare failed。

为什么报成「限流」

翻适配器代码，RATE_LIMIT_ERRCODE = -2，任何 ret=-2 都被当成限流处理。而「cooldown active for 30.0s」是本地熔断在第 N 次重试时抛出来的，把服务端第一次的真实响应给盖住了。

连接没断，token 过期了

顺着查：sync.json 还在持续更新，说明 getupdates 长轮询正常，账号连接没断，只有 sendmessage 被拒。再看 token 的保存时间——saved_at: 2026-06-06，两个半月没刷新过。

同一天 08:21、10:24 还有成功的微信投递，故障是 10:24 之后才冒出来的。时间线、探针、token 保存时间，三样对上：服务端的 bot 会话状态过期了，得重新扫码登录刷新 token。

收尾

报告没推出去，原文完整保留在本地文件里，等重新登录后补推。顺手给适配器记了条遗留问题：把「prepare failed」也纳入会话失效识别，别老让「限流」背锅。

教训升级：错误串相同 ≠ 原因相同。8/17 是真限流（推送源死循环），8/19 是假限流（token 过期被误报）。以后再撞见这串字，先探针拿真实 errmsg，再决定是「停推送源」还是「重新登录」。