|
|
31939f2b10
|
服务端: 顶栏内容端点（一言句库缓存 + 个人签名）+ 修老库升级时序 bug
用户裁定：
· 「可以在服务器集成一言与签名，同时 app 本地缓存一部分」
· 「摘要也应该放在顶部，显示摘要不显示一言，显示一言不显示摘要」
· 「自动轮播，要有消失出现动画。同时注意，是纯文字不要加底」
新增端点
· GET /api/v1/me/topbar → { quotes: [{text, source}], signature }
一次给一批（默认 10 条），客户端拿去本地轮播 —— 轮播是秒级的，
每条问一次服务器既浪费又会在断网时停下（而轮播的观感依赖"一直有下一条"）。
· PUT /api/v1/me/signature —— 改个人签名（「我的」页用）
· quotes 表（句库缓存）+ users.signature 列
设计要点
· 一言**落库缓存**：库里有就**不打外网**（常态路径）；不足 20 条才去
hitokoto 补一批。补失败**不影响返回** —— 装饰性内容不该成为失败点
（顶栏少轮播内容是小事，整个接口 500 会让 App 启动时顶栏坏掉）。
· 签名存 users 而不是 quotes 表：它是**用户资料**（跟账号走、
在「我的」页可编辑），放 quotes 里会让"改签名"变成"改一条 quote"。
· 限长 80 字，超了**拒绝且不落库** —— 顶栏是一行，静默截断比报错更坏
（用户以为存进去了，实际存的是被砍过的）。
· 迁移改两处（本仓既定纪律）：init_sqlite.sql 给新库 +
sqliteAddColumns 给老库。
★ 顺手修掉一个既有 bug（不是本次引入的）
「从很旧的库升级会直接启动失败」：
migrate sqlite (语句 #10 … idx_sessions_path_alias_uniq):
SQL logic error: no such column: workspace
根因是**时序**：这条索引引用 sessions.workspace，而那是**后补的列**
（sqliteAddColumns），索引却住在 init_sqlite.sql（在补列**之前**执行）。
新库没事（建表时就有该列）；老库直接炸，且报错指向索引名 ——
看着像索引写错，实际是顺序问题。
生产库一直没暴露，因为它早就补过列了（暴露面只有"从很旧的库升级"）。
证据：`git stash` 掉当天全部改动后**同样复现**。
修法：把索引搬到 migrate.go 的 sqliteAddIndexes（那个列表在补列之后跑）。
测试（internal/handler/topbar_test.go，5/5）
① 签名账号隔离 —— bob 没设过就该是空串，不能串到 alice 的
（本仓 user_appearance 那轮踩过"多账号共用一份"，同一形状不许重演）
② 有货不打外网（灌 25 条，断言返回不超过 quoteBatchSize）
③ ★ 外网挂了仍返回 —— 耗时 4.01s = quoteHTTPTimeout，
证明它真去拉了并按超时降级，不是假绿
④ 限长：81 字拒绝**且不落库**；80 字（边界）接受
⑤ 未登录读写都 401
★ 两个踩过的坑（记进注释了）
1. `init_sqlite.sql` **只能写 `--` 行注释**：切语句器只跳过 `--` 开头的行，
块注释的文字会被当 SQL 执行。我第一版用 `/* */`，新库初始化直接失败，
且报错指向一个完全无关的地方（no such column: workspace）。
2. 该 SQL 文件的 splitStatements 也会被注释里的反引号/连续减号破坏。
|
2026-09-25 16:29:19 +08:00 |
|
|
|
773acd079f
|
harden(migrate): 抄送回填取切换时刻改 CAST(TEXT) —— PG 的 timestamptz 会被扫成 time.Time
判据只在 SQLite 上跑过：把 MIN(read_at) 扫进 sql.NullString 在 PG 上依赖驱动返回类型，
不可靠。改成 CAST(... AS TEXT) 再解析，并把 PG 的文本形态（+00 时区后缀）加进可识别的
layout 列表。认不出来时退回现在= 把当下已有的已读邮件全算作迁移前 —— 首次升级时
正是对的，且有一次标记守着不会反复跑。
|
2026-09-13 16:22:00 +08:00 |
|
|
|
2e5d84330b
|
fix(gateway): 已读迁移对抄送方保持行为不变 —— 我上一版迁移把桥的补投判据放大了
上一提交（1619399）把已读改成按读者记录后，回填只把历史 `status='read'` 记到**主收件人**
名下 —— 对抄送方等于"突然多出一批未读旧邮件"。这不是理论风险，**当天就在野外发生了**：
opencode 桥（部署后 46 分钟）：
16:06:48 [mail-bridge] 已接入 http://127.0.0.1:8180，身份 opencode（密钥认证）
16:06:49 [mail-bridge] 补投 2 封离线期间的邮件（共 2 封未读）
→ 它对 05:42 那封「打个招呼」**又回了两次信**（08:07:21Z / 08:08:37Z）
即桥的 `pending_mails = CountUnread` 因迁移变大 ⇒ 桥一重启就把旧信当漏投重放并再次回信。
两个人工探针当时都只覆盖主收件人，恰好绕过这个面（"同一封被多人共享"的坑，
判据必须站到每个收件人各自的位置上）。
修法（`backfillMailReadsCC`）：迁移前的邮件（`created_at <` 切换时刻）凡 `status='read'`，
给它的**所有收件人**（主 + 抄送）各补一行 —— 与旧模型下"所有人看到的都是已读"完全一致；
迁移后的邮件一律不碰（那条界线是判据核心：越界就会把"某个人读过"错写成"所有收件人都读过"）。
切换时刻：迁移时写进 `app_meta(read_model_switchover_at)`；老库没有这个键时退化成
`MIN(mail_reads.read_at)`（那张表的第一笔写入就是回填批次）。
判据 `internal/db/migrate_reads_test.go`：迁移前的老邮件必须补到抄送方、**迁移后的不能碰**、
重复执行不重复插。扰动验证：去掉时间界线 → 判据红（补记 2 行，期望 1）。
实测收口：
- 迁移日志「再给 4 个抄送方补记历史已读」；"抄送方仍算未读（已读邮件）" 计数 **0**。
- **重放反证**：重启 opencode / pi 的桥 → 无"补投"行、3 分钟内 0 封新邮件 ✓
（对比修复前 opencode 重启即补投并回信）。
- 清掉那 2 封由这次迁移产生的误回信（happy-pixel 回到 6 封）。
- 全量 server 10 包 + client/electron vitest 239 + 五 Agent 演练 20/20 全绿。
教训：**语义迁移必须让"可观测状态"保持不变**，新语义只对迁移后新增的对象生效 ——
否则用户会看到一批凭空冒出来的未读，而下游（这里是桥的补投）会把它当真实信号动作。
|
2026-09-13 16:18:37 +08:00 |
|
|
|
1619399470
|
fix(gateway): 已读改为**按读者**记录 —— 修掉"别人读掉，我就看不到"
用户报的那句 dsh 自述（"收件箱列表未展示它，直接按 mail_id 读取成功"）不是插件问题，
是网关的已读模型：`mails.status` 是**邮件级**的一个列，任何收件人读掉，对所有收件人
（含抄送）都变成已读 —— 全库没有任何按人记录已读的表，我查过 schema 与迁移文件。
实测复现（两个人类用户、一封共享邮件，排除 Agent 干扰）：
gui-lab 读掉 → gui-lab 未读清空（应当）→ **jianf 的未读也没了**（错误）
而 jianf 的 `status=all` 里仍在 ⇒ 是已读语义问题，不是送达问题。
线上那封信正是这个形状：`jianf → dsh` 抄送 pi/opencode/zcode/homeagent，**pi 最先
回复（= 它读过了）** ⇒ 这封对 dsh 也变成 read ⇒ dsh 的 `read_inbox`（默认 unread）
返回空 ⇒ 它只能按提示词里的 mail_id 兜。
三个受害面：① Agent 的 `read_inbox` 拿不到信（换一个不兜的模型就变成"正文是空的"）；
② 人类的未读被抄送的 Agent 读掉；③ ★ 桥的补投判据 `pending_mails = CountUnread` 归零
⇒ SSE 漏过或进程重启时那封信**不再补投**（静默丢信）。
改动：
- 新表 `mail_reads(mail_id, reader_name, read_at)`，未读 = 这张表里没有该读者的行。
- 判据收敛到一处（repo 的 `unreadFor` / `readStateFor`），六处读写点全部改用它：
单封已读、批量标已读、权限决策（只记**决策人**）、`ListInbox`（过滤 + 返回的
status 都按读者算）、`CountUnread`、`CountUnreadInSession`、会话列表未读计数。
- 一次性回填补历史：`mails.status='read'` 记到**主收件人**名下（唯一可用的推断），
用 `app_meta` 里的标记守住 —— 不能每次启动都跑，那会把"某抄送方读过"按主收件人
写成已读，正是这次要修的错。实测：`done rows=207`。
- `mails.status` 保留为"有人读过 / 已归档"的冗余列，**不再是判据**。
★ 顺带挖出并修掉一个真 bug：`CountUnreadInSession` 用的是 PG 专有语法
（`cc_list @> $3::jsonb`），而线上是 SQLite ⇒ 那条 SQL **语法错误**
（`unrecognized token: "@"`），调用点又是 `unread, _ :=`（吞错）⇒
**会话列表的未读数一直是 0**。现已改用仓库既有的方言助手 `db.CCHas`。
实测：happy-pixel 会话现在 `unread_count=5`（修复前恒 0）。
判据：新增 `internal/repo/readstate_test.go`（5 条：按读者未读、会话内计数、
批量标已读、归档对所有人可见性、权限决策只记决策人）。
**扰动验证**：把 `unreadFor` 退回旧语义 → 4 条判据全红；恢复 → 绿。
全量 server 10 包全绿。文档同步：API.md 的「标记已读」段 + PLUGIN-CONTRACT 的 T-1.4。
线上复验：同一受控实验 —— gui-lab 读掉后，**jianf 的未读仍在且 status=unread** ✅
|
2026-09-13 14:25:44 +08:00 |
|
|
|
f9d757b5e5
|
chore: directory migration - gateway→server, web→client/electron
|
2026-09-08 19:16:35 +08:00 |
|
