qq-bot-roost 0.9.1 → 0.9.2

package/README.md

@@ -10,7 +10,7 @@
 <img src="https://img.shields.io/badge/dependencies-0-brightgreen" alt="零依赖">
 <img src="https://img.shields.io/badge/tests-700%2B%20passed-brightgreen" alt="测试 700+ 项">
 <img src="https://img.shields.io/badge/plugins-JS%20%7C%20Python%20%7C%20Go%20%7C%20any-blue" alt="多语言插件">
-<img src="https://img.shields.io/badge/version-0.9.1-blueviolet" alt="版本 0.9.1">
+<img src="https://img.shields.io/badge/version-0.9.2-blueviolet" alt="版本 0.9.2">
 <img src="https://img.shields.io/badge/license-Non--Commercial-red" alt="禁止商用">
 <a href="https://github.com/tdcq9594/qq-bot-roost/actions"><img src="https://img.shields.io/github/actions/workflow/status/tdcq9594/qq-bot-roost/ci.yml?branch=master" alt="CI"></a>
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "qq-bot-roost",
-  "version": "0.9.1",
+  "version": "0.9.2",
   "type": "module",
   "description": "栖 Roost：零依赖的 QQ 官方机器人框架，填 AppID/AppSecret 即连，插件可写任意语言",
   "license": "SEE LICENSE IN LICENSE",

package/src/delivery.js

@@ -267,5 +267,80 @@ export function createDeliveryLedger({ db, botId, log = () => {} }) {
     }
   }
 
-  return { claim, settle, settleByMsgId, recoverPending, get, recent, stats };
+  /**
+   * 一条逻辑消息可能对应好几行。
+   *
+   * 为什么：被动回复超过 1800 字时，发送层会切成几块各发一次，
+   * 每块一个幂等键（`${base}#1`、`${base}#2`…，见 ai-chat 的 `sendReply`）。
+   * 这是必须的——共用一个 id 的话第 2 块起会被 `claim` 判成 `reuse` 直接丢掉。
+   *
+   * 但「这条消息到底送没送到」问的是**整条**，不是某一块。所以这里把
+   * base 和它的所有分块聚合成一个状态。
+   *
+   * 聚合规则按「坏消息优先」：只要有一块 `unknown`，整条就是 `unknown`
+   * （**绝不能重发**——重发会把已经出去的那块再发一遍）；有一块 `failed`
+   * 就是 `failed`（可重试，重试只会补没发出去的那块，因为 id 是确定的）；
+   * 还在飞就是 `pending`；等审核是 `audited`；全成功才是 `sent`。
+   *
+   * @param {string} requestId base id
+   * @returns {null | {state:string, parts:number, msgId:string, code:string,
+   *   attempts:number, at:number, rows:object[]}}
+   */
+  function family(requestId) {
+    if (!ready()) return null;
+    const base = String(requestId ?? '').trim();
+    if (!base) return null;
+    /**
+     * `LIKE` 里的 `%` `_` 要转义，否则 base 里带这两个字符会误匹配到别人的行。
+     * requestId 是我们自己生成的（`qs-…` / `sp-…`），正常不会有，
+     * 但这里是公共入口，不能靠上游自觉。
+     */
+    const esc = base.replace(/[\\%_]/g, (m) => `\\${m}`);
+    try {
+      const rows = db
+        .prepare(`SELECT * FROM deliveries WHERE request_id = ? OR request_id LIKE ? ESCAPE '\\' ORDER BY request_id`)
+        .all(base, `${esc}#%`);
+      if (!rows.length) return null;
+
+      const rank = {
+        [DELIVERY_STATE.SENT]: 0,
+        [DELIVERY_STATE.AUDITED]: 1,
+        [DELIVERY_STATE.PENDING]: 2,
+        [DELIVERY_STATE.FAILED]: 3,
+        [DELIVERY_STATE.UNKNOWN]: 4,
+      };
+      /**
+       * 认不出的状态**不参与比较**，不能给它一个默认名次。
+       *
+       * 给 0（等于 sent）会让一条状态坏掉的行被当成已送达；
+       * 给 99（等于最坏）又会让它压过真正的 `unknown`，把「绝对不能重发」
+       * 这条信息淹掉。两种情况都会让人对着一个假答案往下走。
+       *
+       * 正常不会出现（`settle` 会校验状态），但账本是跨版本存活的，
+       * 老版本写过什么值谁也不敢保证。
+       */
+      const known = rows.filter((r) => r.state in rank);
+      const pool = known.length ? known : rows;
+      let worst = pool[0];
+      for (const r of pool) if (rank[r.state] > rank[worst.state]) worst = r;
+      if (!known.length) log(`投递账本里有认不出的状态：${rows.map((r) => r.state).join('、')}`);
+
+      /** 报最坏那块的 msg_id / code，人核对时想知道的是「哪块出问题了」 */
+      const at = rows.reduce((m, r) => Math.max(m, Number(r.settled_at || r.created_at || 0)), 0);
+      return {
+        state: worst.state,
+        parts: rows.length,
+        msgId: worst.msg_id || '',
+        code: worst.code || '',
+        attempts: rows.reduce((m, r) => Math.max(m, Number(r.attempts || 0)), 0),
+        at,
+        rows,
+      };
+    } catch (e) {
+      log(`投递账本家族查询失败：${e.message}`);
+      return null;
+    }
+  }
+
+  return { claim, settle, settleByMsgId, recoverPending, get, family, recent, stats };
 }

package/src/message.js

@@ -549,11 +549,17 @@ export function buildMessage(eventName, d, { api, cfg, outbound, session }) {
     return send({ content: String(text), ...opts }, false);
   };
 
-  /** Markdown 消息（可带按钮 keyboard）。Markdown 是独立消息类型，先把攒的文本发掉 */
-  msg.replyMarkdown = async (markdown, keyboard) => {
+  /**
+   * Markdown 消息（可带按钮 keyboard）。Markdown 是独立消息类型，先把攒的文本发掉。
+   *
+   * `opts.requestId`：投递账本的幂等键。以前这条路完全绕开账本——
+   * 插件给了 id 也只对纯文本生效，markdown 那条永远记不上，重发就会重复。
+   * 第三个参数是可选的，老调用方不传，行为不变。
+   */
+  msg.replyMarkdown = async (markdown, keyboard, opts = {}) => {
     await msg.flushReplies();
     try {
-      return await send({ markdown, keyboard }, true);
+      return await send({ markdown, keyboard, ...(opts?.requestId ? { requestId: opts.requestId } : {}) }, true);
     } catch (e) {
       /**
        * Markdown 是**独立消息类型**，没有纯文本兜底：平台不放行（没权限、
@@ -581,7 +587,13 @@ export function buildMessage(eventName, d, { api, cfg, outbound, session }) {
        * 按钮里的指令本来也会出现在正文里（ctx.menu 渲染时带上），信息不丢。
        */
       log.warn(`Markdown 被拒（${e.message}），降级为纯文本重发`);
-      return send({ content: plain }, true).catch((e2) => {
+      /**
+       * 降级重发**沿用同一个 requestId**：对用户来说这仍然是「一条消息」，
+       * 账本里就该只有一行。上一步抛错时已经结算成 `failed`（可重试），
+       * 所以这里 claim 会放行并复用同一行，最终状态是 `sent`。
+       * 万一是 `unknown`，claim 会抛错——那正是我们要的「不重复发」。
+       */
+      return send({ content: plain, ...(opts?.requestId ? { requestId: opts.requestId } : {}) }, true).catch((e2) => {
         log.error('降级纯文本也没发出去:', e2.message);
         return null;
       });