PR审查

[phantom5099]

#343

结论

会有压力，而且在你这个会话场景里通常不划算把图片二进制直接塞进 SQLite 主库。你们这次 PR 采用的“附件落盘 + SQLite 存元数据”是更稳妥的默认方案。

对比（结合当前 PR）

1. 图片直接存 SQLite（BLOB）

• 优点：事务一致性最好（消息与图片可同事务提交）、备份恢复单文件简单、路径管理更少。
• 缺点：session.db 体积增长快，WAL/Checkpoint 开销上升；大对象读写会拉高锁等待与 I/O 峰值；VACUUM/备份/同步变慢；热点查询更容易被大页读拖慢。

2. 图片存本地目录，SQLite 只存路径/元数据（你们当前方案）

• 优点：数据库保持轻量，消息增量写入更稳定；大文件 I/O 与结构化查询解耦；列表、摘要、分页查询性能更可控。
• 缺点：需要处理“DB 记录与文件”双写一致性（孤儿文件/悬挂记录）、搬迁与备份要同时覆盖 DB+assets、路径安全与清理策略要做好。

建议

• 对 NeoCode 这种“文本消息高频 + 图片附件低频且可能偏大”的负载，优先保持现在方案。
• 若后续要进一步增强可靠性，可加三件事：

1. 启动时或定时做 session_assets 与磁盘文件对账修复。
2. 明确原子写流程（先临时文件再 rename，再写元数据；失败回滚清理）。
3. 备份/迁移工具强制打包 session.db + assets/，避免只备份其一。

本次完成情况

• 已完成：问题分析与两种方案优劣对比，并给出针对本 PR 的落地建议。
• 未执行：未做代码改动、未新增测试（本次是分析答复）。

View job run

[phantom5099]

@xgopilot 分析343PR还有没有类似的修改过后变化的行为

[fennoai]

结论

有，PR343 除了“附件落盘 + DB 存元数据”外，还存在几类修改后行为变化。我按是否影响业务语义分了级：

发现的行为变化

1. 会话持久化粒度已改变（实现层，低风险）

   • 从“整会话覆盖写入（Save）”改为“意图型增量写入（CreateSession/AppendMessages/UpdateSessionState/ReplaceTranscript）”。
   • 位置：internal/runtime/session_mutation.go、internal/runtime/session_scheduler.go、internal/session/sqlite_store.go

2. 存储形态已改变（运维层，中风险）

   • 从 sessions/<id>/session.json 改为工作区级单库 session.db + assets/。
   • 位置：internal/session/workspace.go、internal/session/store.go、internal/session/sqlite_store.go

3. 列表容错行为已改变（可观察行为，中风险）

   • 旧实现会在 ListSummaries 中跳过损坏/不可读的单个会话文件继续返回其余结果；新实现依赖单库查询，数据库层异常会直接返回错误。
   • 位置：internal/session/store.go（旧逻辑）对比 internal/session/sqlite_store.go（新逻辑）

4. 运行时关闭行为已改变（资源管理，低风险）

   • runtime 关闭时新增 sessionStore.Close()，避免 SQLite 连接泄漏。
   • 位置：internal/app/bootstrap.go

是否有“同类问题”

当前 diff 中未看到和“图片二进制直接入库”同级别的新业务语义偏移；主要是持久化实现与容错模型变化。需要重点关注的是第 3 点（单库故障时影响面更集中）。

本次完成情况

• 已完成：对 PR343 相对 origin/main 的改动后行为变化分析与风险归类。
• 未执行：未做代码修改、未跑额外测试（本次为分析答复）。

View job run