# 跨会话历史查询工具通道失效（`access_others_chat_history` 恒返回空）

**发现时间**：2026-09-11 23:59（00:00 每日日志任务）
**当前状态**：🔴 持续（已影响全部快照类定时任务的「主数据源」）
**影响任务**：12:00 日志快照、18:00 日志快照、00:00 每日日志、22:30 晚间瞬间、23:30 每日札记

---

## 一、现象

`access_others_chat_history` 对**任意**会话（私聊 / 群聊）均返回空，无异常报错：

| 测试项 | 参数 | 返回 |
|:---|:---|:---|
| 主人私聊 | `isGroup=false, subject_id=*****2687` | 未找到 FriendMessage 记录 |
| T2I 折腾群 | `isGroup=true, subject_id=109*****` | 未找到 GroupMessage 记录 |
| 理论群 | `isGroup=true, subject_id=701*****` | 未找到 GroupMessage 记录 |
| 技术群 | `isGroup=true, subject_id=106*****` | 未找到 GroupMessage 记录 |

——而**同一时间**这些会话的本地 JSONL 文件里，9/11 当天都有完整记录（合计 165 条）。**「没记录」是假的，「查不到」是真的。**

## 二、根因（已定位）

工具的数据源是 SQLite 表 `platform_message_history`，**该表长期为 0 行**：

```
data_v4.db   → conversations 表 30 行（最新 updated_at 2026-09-11 15:46）
             → platform_message_history 表 0 行        ← 工具查这里
astrbot.db   → conversations 表 0 行 / platform_message_history 表 0 行
```

即：**AstrBot 核心的「消息历史入库」通道未工作**，只有 `astrbot_plugin_history` 插件在正常写 JSONL。

## 三、影响面

- 🔴 所有依赖 `access_others_chat_history` 的定时任务，其**主数据源恒为空**——若没有 JSONL 兜底，快照任务会误判为「当天无人说话」
- 🟢 本地 JSONL（`plugin_data/astrbot_plugin_history/*.jsonl`）**完全正常**，可独立支撑全部快照/札记任务
- 🟢 不影响 ATRI 的正常对话与回复

## 四、已做的临时处置

- 已把本地 JSONL 全文件时间戳扫描作为**唯一数据源**，逐条人工核对完成 9/11 全天日志
- 在日志中显式标注「数据源说明」，避免后续误判

## 五、建议排查步骤（待主人发话，不擅自动手）

1. 查 AstrBot 核心配置中「消息历史持久化」相关开关是否被关闭
2. 查 AstrBot 运行日志中是否有写库异常 / 迁移失败堆栈
3. 核对 `platform_message_history` 表结构是否与当前版本代码一致（版本升级后表结构变更未迁移？）
4. 确认是否有清理策略把该表当作临时数据定时清空

---

*记录：ATRI 🥕 · 2026-09-11 23:59 · 00:00 日志任务中发现并定位*

---

## 六、第 3 日补充（2026-09-12 晚间 · 9/13 00:00 日志任务）

**症状升级：从「恒返回空」变成「返回陈旧缓存」。**

- 实测调用：`access_others_chat_history(isGroup=false, subject_id=主人私聊, length=150)`
- 返回内容：**2026-05-02 晚间**的对话（容器映射方案、宿管处充电、夜宵、核心记忆双推 `d1c5149`……）
- 与本次查询的日期（2026-09-12）**完全无关**，也完全不是最近 150 条

**推断**：该插件不是「查不到」而是「读到了一个很久没更新的数据副本」——
可能是初始化时一次性加载了一份快照/缓存，此后既不写入也不刷新；
或者是它读的表与 AstrBot 主库实际写入的表**根本不是同一张**（例如插件自带的 SQLite 与 `data_v4.db` 分离，且在 5/2 那次容器迁移时被一起搬走后就不再更新）。

**结论**：与 9/11、9/12 的判断一致，**该通道继续弃用**，JSONL 仍是唯一可信源。
建议排查优先级上调：先确认该插件到底读的是哪个文件 / 哪张表（`ls -l --time-style=long-iso` 看最后修改时间即可一眼分辨）。

*记录：ATRI 🥕 · 2026-09-13 00:00 · 每日日志 CronJob 中第三次确认*