Branch:
along-test
along
along-test
main
memory-center-impl-v1
memory-design-v0.2
${ noResults }
2 Commits (along-test)
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
811a008545 |
services: 语音纪要→拾忆→MCP 链路审计落地;修两个「什么都没发生」的既有 bug
审计与落地计划见 docs/语音纪要-拾忆-MCP链路审计与落地计划.md,已在阿龙测试环境 逐条验收通过(记录见该文档 §5.1)。 ## 安全 echomeet 八个按 id 操作的接口**一处都没有比对 record.Uid 与会话 uid**,任何登录用户 改一个 id 就能读别人纪要全文、删改别人的记录、给别人的记录发起总结(扣自己算力, 但覆盖对方 summary 并触发对方的拾忆抽取)。统一改走带 uid 的查询: - 「不存在」与「不是你的」回同一个错误码同一句话——分开回等于给出一个探测他人 id 的接口;用的还是改动前记录真不存在时的 DBError,合法用户行为无任何变化; - 批量接口按交集处理、**不报错**:客户端轮询队列里本就可能留着已被别的设备删掉的 id, 报错会把整个轮询循环掀掉;delrecords 响应回实际删掉的那批; - starttask 的校验排在扣算力之前,否则拒绝了还先把钱扣了; - 回调接口是第三方来的、没有 session,不在此列。 - TestApisUseUidScopedQueries 扫源码守着:最容易复发的不是有人改回去, 而是新加接口时照旧写法抄一遍,那样既不报错也看不出来。 ## gorm 的 default: 标签吞零值 mysql.Insert = db.Table().Create(model),gorm 对带 default: 的字段**一律把零值换成 默认值**。DBMemoryItem 的 date_certain(default:true) / remind_ahead(default:5) 因此 永远写不进 false/0:测试库 25 条记录全部落成 1/5,「待定日期」分组恒为空, 会议待办还会在 08:55 响提醒——与「会议待办默认不提醒」正好相反。 ⚠️ 加 Select("*") **救不了**:替换在 ConvertToCreateValues 的 reflect.Struct 分支里 无条件做,只看值是不是零值,与 Select/Omit 无关(DryRun 实测两种写法生成的 VALUES 一模一样)。改成插入后把这两列按结构体现值补写回去,并把真值还给调用方—— gorm 连结构体上的字段一起改了,不还原的话 memory_add 回给客户端的也是错的。 存量由 migrate_defaults.go 幂等修正(只碰 source=meeting 且 user_edited=0)。 ## 内容门槛 6 秒的测试通话、20 秒的单人自述照样被抽成「继续进行进一步的功能测试」这类废话待办, 再靠条数凑够周报阈值又触发一次 LLM 调用。门槛卡**转写正文**不卡纪要——内容太薄时 模型按模板兜底规则照样能写出六百多字。只拦抽取与 MCP 检索,**纪要照出**: 短语音备忘是合法用法,也不判成 SummarizFail(客户端把那个码显示成「请稍后重试」, 用户会一直点)。数据缺失时按通过处理,不因上游漏传一个字段就静默关掉抽取。 ## 其余 - 报告补偿:原先的 requeueIfStale 由 memory_getreport 驱动,而客户端调无参版本 → 走 latestUnconfirmedReport,那条 SQL 只查 state=Done,pending/processing/failed 永远查不出来也就永远补不了。新增 ensureRecent 挂在 memory_today:漏建的补建 (过与 cron 同一道条数闸门)、卡住的复用 requeueIfStale、失败的至多重试 3 次 (计数寄在 error_msg 的 retry=N; 前缀,fail() 必须保住它,否则上限形同虚设)。 加 enqueueOnce 判重与按报告 id 的 SETNX 生成锁,cron 与 ensure 撞上只跑一次 LLM。 - 说话人标签:finishSyncTranscribe 拼的是「Speaker 0」(空格)、其余是「Speaker_0」, 抽出来的负责人就成了 Speaker2、[Speaker_0] 各种样。四条写入路径统一走 normalizeSpeakers, 顺带修掉没开说话人分离时拼出「Speaker_」空尾巴。 - 时区:LoadMemoryLocation 现在认 IANA / 固定偏移 / CST(按 Asia/Shanghai 解释, 兜住已落库那批),认不出来仍退服务器本地时区但**打 warn**——原来是全静默的。 - 删纪要连带删自动待办(只删 user_edited=0),查询带 uid:入参来自删除请求, 光信 source_id 等于把归属校验的成果又丢一次。 - 回调幂等:两个回调既不看状态也不抢锁,与轮询撞车就各翻译一遍、各入队一次。 失败分支同样要过闸门——一条已 Completed 的记录被迟到的失败回调打回 TranscribeFail, 用户看到的就是「纪要好端端地变成了转写失败」。挡下来仍回 SUCCESS,不让第三方重投。 SubmitAITask 保持不判重(用户点的「重新生成」悄悄跳过等于按钮失灵), 自动路径改走 submitAITaskOnce。 - 重复项统计:只展开闹钟。花销展开等于虚构金额,待办的 done/undone 按次拆不开。 ## 顺带修的两个既有 bug(部署验收时挖出来的) happen_date / period_start 都是 type:date 列 + DSN parseTime=True,读进 Go 的 string 是「2026-09-07T00:00:00+08:00」。SQL 比较靠 MySQL 转换还是对的,所以这个问题 **在任何日志任何报错里都看不见**,只在 Go 侧解析它的地方发作: 1. remind.go 的 expandItem 解析不了 → **memory_upcoming 恒返回 0 个提醒时刻, 整个拾忆提醒在服务端一直空转**(真机实测:建一条每天 08:00 的闹钟,slots 为 []); 2. 下发给客户端的 happen_date 一直是 RFC3339 而非协议约定的 YYYY-MM-DD, 客户端 _localToday() 的字符串相等比较恒不匹配、_mergeRange 在区间端点会重复。 这也是审计里「会议待办会在 08:55 响通知」只能是推演的原因:实际一条都不会响, 两个 bug 互相遮蔽。修法两层:ParseMemoryDate 容忍带时间的形式(安全网), 读路径出口统一归一(管对外格式),缺任一层都会留坑。 ## 列表骨架化(同批) echomeet_getallrecords 只回列表要用的骨架字段,original/translate/summary 占每条 97% 的字节(实测 59 条 ≈ 500KB,列表用得上的 15KB)。 ⚠️ 骨架记录**绝不能写回库**:mysql.Save 是整行 UPDATE,三列会被清空。 StartTask 允许对已完成/已阅/失败的记录「重新转写」,那期间 state=Transcribing 而旧 纪要还在库里,用户切一下列表页旧转写和旧总结就没了。轮询前重新取整条再操作, TestListEndpointNeverSavesBriefRecord 守着不许回退。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
3 weeks ago |
|
|
715f8e3818 |
上传厨师版本
|
4 months ago |