mirror of
https://gitcode.com/JianFeeeee/homeagent-sdk.git
synced 2026-10-31 06:17:25 +00:00
65d2bd9e61
生产实测（2026-10-13）：一次回复发出 4 条相同消息，日志中 3 次 output_send__qq 的调用 id 各不相同 —— 是模型看到「发送失败」后自己重试。 根因（在 NapCat 运行代码 /app/napcat/napcat.mjs 中确认）： sendMsg 把消息交给 QQ 内核后，等 onMsgInfoListUpdate 事件匹配 guildId + KSEND_STATUS_SUCCESS，内部固定等待 10s（附件更长）。 主机 IO 饱和（iowait 94–96%）时主线程被 10–30s 长任务阻塞，回调排不上队， 于是 NapCat 抛 "Timeout: NTEvent ... sendMsg" → 非零 retcode（实测 200）。 但消息**已被 QQ 送达**：同一窗口内确有 16 条「发送 -> 私聊」成功记录。 这与已修的 HTTP 客户端超时是两条不同路径： - HTTP 超时：client.Post 返回 err（bd26c2a 已告警） - NapCat 超时：HTTP 200 + 响应体带 NTEvent 字样（本次补） 只报「失败」不说「可能已送出」，模型必重发。 改动： - napcat() 对发送类动作（napcatSendActions）的 NTEvent 超时包装 errNapcatTimeout，并附「很可能已送出、不要盲目重发」的告警； 查询类动作保持普通失败（可安全重试）。 - 不按 retcode 判定：该超时来自 callNormalEventV2 的普通 Error， retcode 本身不携带「超时」语义。 - 不以 serviceAndMethod == sendMsg 为条件：调用方已限定发送动作， 该收紧既无生产证据支持，又会把同类超时退回普通失败重新诱发重发。 测试（全部穿过 napcat() 真实调用链）： - TestNapcatSendTimeoutWarnsAgainstBlindResend（生产原文 retcode=200） - TestNapcatQueryTimeoutIsNotSendTimeout - TestNapcatSendActionTimeoutRegardlessOfServiceName 变异验证（3 项，均按预期失败后退回）： ① 删告警分支 → 发送用例失败 ② 加回 sendMsg 限定 → 不限服务名用例失败 ③ 去掉发送动作门禁 → 查询用例失败