# 飞书会话膨胀 + state.db 损坏修复（2026-07-28）

## 飞书会话膨胀

### 症状

飞书消息回复极短（3-7 字符），Gateway 日志显示大量 `APIConnectionError`。
会话 ID 固定（如 `20260727_084209_a2460379`），消息数累积 1000+。

### 根因

同一飞书 DM 会话从早到晚未 `/reset`，上下文无限膨胀。
每次 API 调用发送全部 1000+ 条历史消息 → 超时/连接失败。

### 诊断

```bash
# 检查 Gateway 日志中 session 的 disk/memory 消息数
grep "Persisted transcript lagged" ~/.hermes/logs/gateway.log | tail -5
# 示例：disk=1019, memory=1025 → 1000+ 消息
```

### 修复

用户在飞书发送 `/reset`，或在 Gateway 重启后打开新会话。

### 预防

- 飞书会话每隔 200 条消息建议 `/reset`
- 可在 cron 中加入定期清理逻辑

---

## state.db 损坏修复

### 症状

`PRAGMA integrity_check` 报 btree/freelist/page 错误。
Gateway 日志 `database disk image is malformed`。

### 已尝试的修复方法及其结果

| 方法 | 结果 |
|------|------|
| `VACUUM` | 数据库反而变大（276→274MB），因为 FTS 表重建 |
| `VACUUM INTO` | 同大小，无效 |
| `.clone` | 产出**更损坏的数据库**（0B 或缺少表），不可用 |
| `.dump` + 重建 | UNIQUE 约束冲突（源数据已有重复行），回滚后 0B |
| 删除 FTS 重建 | 数据库太损坏，INSERT 失败 |

### 最终有效方法：新建 + JSONL 备份

```bash
# 1. 确认 JSONL 备份存在
ls ~/.hermes/sessions/*.jsonl | wc -l  # 应有 N 个备份文件

# 2. 停止 Gateway
hermes gateway stop

# 3. 备份损坏文件（以备不时）
mv ~/.hermes/state.db ~/.hermes/state.db.corrupt
rm -f ~/.hermes/state.db-shm ~/.hermes/state.db-wal

# 4. 重启 Gateway — 自动创建新 state.db
hermes gateway start
```

### 教训

- **不要用 `.clone` 修复损坏的 SQLite 数据库**——它会产出更坏的副本
- **不要用 `.dump` + 重建**——导入时的错误会导致整个事务回滚（0B 文件）
- **定期维护**：`hermes sessions prune --older-than 60` 减少膨胀
- **JSONL 备份是救星**：`~/.hermes/sessions/` 下的 JSONL 文件独立于 state.db
