[bug] Codex 会话文件被重编码后，增量扫描重放同一消息 ID 触发幂等 409，「同步新增」永久报「扫描失败」

[QDcvd]

现象（Symptoms）

• 对 Agent 源 Codex 执行扫描，界面一直报「扫描失败」。
• memory.log 每次扫描出现 6~12 条："statusCode":409,"error":"conflict","message":"idempotency key reused with different request body"
• 扫描源水位（latest_seen_created_at）永久停在失败前的值，不再推进；之后每次重扫必失败（死循环）。
• 手动把水位推进到「最新」可临时恢复一次；但 Codex 对已导入过的会话文件再次改写，下一轮扫描立刻复发。

环境（Environment）

• Memmy 桌面端 1.1.1（Windows x64；最新 v1.1.2 未见修复，main 分支亦未修复）
• 扫描源：Codex（builtin），数据目录 C:\Users\user.codex\sessions（JSONL rollout）
• 复现会话：rollout-2026-09-07T00-54-21-01a077a4-….jsonl（约 8.4MB，消息 >1100 条）

复现步骤（Steps to reproduce）

1. 用 Codex 开启长会话并持续使用数小时。
2. Memmy 首次增量扫描成功导入部分消息（实例：导入至消息 :964，checkpoint 07:18:50Z）。
3. Codex 继续使用/对该 rollout 文件重编码改写（mtime 更新、已导入消息正文序列化变化、追加新消息）。
4. 再次触发「扫描 Codex」。
5. 失败：扫描器判定会话「内容修订」整场重放，已导入的同一消息 ID 以不同正文重新提交 → memory/add 幂等层拒绝 → 409 → 扫描整体失败。

预期行为（Expected）

• 增量扫描应正确处理「会话文件被改写」：按 checkpoint 增量跳过已导入部分只导新增；或以更新语义重放（更新既有记忆）而非冲突失败。
• 个别消息冲突不应导致整场失败、水位永不推进（避免永久死循环）。

实际行为（Actual）

• 扫描器检测内容修订后整场重放全部消息（含已导入同一 messageId），memory/add 返回 409，扫描报错。
• agent-source-service 水位仅在整场零错误时推进，一条 409 即永久卡死 → 每小时/每次手动扫描重复失败。
• 用户只能手工改库推进水位临时跳过，代价是该会话历史不再进入记忆。

根因分析（Root cause）

1. Codex 会重写/重编码已导入的会话文件：同一 messageId 的正文序列化发生变化（实证：成功导入后文件被改写，mtime 更新、内容哈希变化）。
2. 扫描器对「内容修订」会话整场重放：findContentRevisedConversationIds() 判定「最新消息游标==checkpoint 但 content_hash 不同」→ replaySeenConversationIds 整场重放。
3. 内存服务幂等层恰好拒绝该重放：memory-service.ts 中 idempotent() 以 key=operation:adapterId:requestId、requestHash=stableHash({operation,fingerprint}) 判重，同 key 不同指纹直接抛 409。

即：扫描器主动检测并重放「内容修订」会话，但 memory/add 幂等层恰恰禁止「同 key 换正文」——重放路径架构上永远走不通；再叠加「水位只在零错误时推进」，形成永久死循环。

影响（Impact）

• 任何「已导入过、之后又被 Codex 改写」的会话都会让 Codex 源扫描永久失败。
• Codex 是活跃使用的 Agent，长会话重编码是常态，高频复发（本机 09-06~09-08 连续三天，数十次 409）。
• 用户无法通过界面恢复，只能手工改库推进水位（有数据丢失风险）。

相关 issue（Related）

• [bug] Agent 源扫描 Skill 层记忆因 createdAt 使用文件 mtime 导致幂等 409，「同步新增」永久报「扫描失败」 #369（Skill 层 mtime 变体，同 409 死循环机制，不同触发点）

附：关键代码位置（main，2026-09-08 仍未修复）

• Memory/src/service/memory-service.ts → idempotent()
• App/backend/src/services/agent-source-service.ts → findContentRevisedConversationIds() + replaySeenConversationIds；水位仅 input.final && stats.errors.length===0 时推进
• App/backend/src/adapters/outbound/agent-source/codex/adapter.ts + conversation-window.ts → 整场会话窗口语义

[pm25coder]

复现路径和根因分析很完整，我在 main 上把两处关键代码对了一遍，补充几个这条死锁里值得拆开的点。

1. 冲突的本质：幂等键的作用域是「尝试」，不是「消息身份」。 memory-service.ts L813-818 的 key = operation:adapterId:requestId，L819 requestHash = stableHash({operation, fingerprint})——这层语义是给「同一请求的意外重试」用的：重试（同 key 同 body）返回 withDuplicateFlag（L825），key 被复用但 body 变了 → 基本可以断定是调用方 bug → 抛 409。但扫描器的整场重放不是重试：它是扫描器主动检测到内容修订后发起的一次新提交，复用了消息的身份却带着新的正文。两层契约是矛盾的——findContentRevisedConversationIds() 的存在就是为了发现「正文变了然后重放」，而 idempotent() 的存在恰恰是为了拒绝「同 key 换正文」。重放路径不是撞上了 bug，是撞上了另一层为自己设计的保护。

2. 代码里其实已经有「良性重复」的分类，只是修订子集没有出口。 同一消息、正文未变 → hash 相同 → duplicate flag → 计入 stats.deduped（ingest 结果里有 deduped 计数，L266/1092）——说明「再次遇到已导入消息」在管道里本就是常态。只有正文变化的那一小撮走 409。而 409 是 throw：要么中断整批，要么作为 error 累积，最后都撞上 L1109-1116 的四条件水位门（errors.length === 0 && incomplete === 0 && failed === 0）→ 水位永不推进 → 下次扫描重放同样的修订子集 → 同样的 409。一个消息毒死整个源，且毒药自稳。

3. 修的方向建议按两层拆：

• 幂等作用域按扫描代际（generation）走：扫描器判定「内容修订、整场重放」时，用带本次扫描代际的 requestId 提交（同代重试 = 同 key 同 body = 幂等；新一代 = 新 key = 合法），409 就只会在真正的「同代同 key 异 body」——即调用方 bug——时触发。旧消息进不去重复（取决于 add 层是否已有 messageId 级去重，见下）。
• 水位按「已处理」而非「零错误」推进：add 的结果分类为 added / deduped / conflict-skipped，409-已知消息归入 conflict-skipped（或 dead-letter 单条记日志），整场扫描只要有分类结果就推进水位——毒药消息不再自稳。想保留「个别会话失败不推进」的防丢语义，可以把粒度从整场降到会话级。

4. 一个值得先做的探针：看 fingerprint 里到底有什么。 如果 fingerprint 包含的是原始序列化（字段序、空白、转义形式）甚至文件级元数据（mtime——#369 是同一家族：正文里带 mtime 的话任何 touch 都变体），那 Codex 的重编码噪音就会淹没语义信号。建议抓一条 409 消息，diff 一下首次导入与重放两次的 fingerprint 输入：如果只是 JSON 序列化形式变了而语义没变，正确做法是按规范化后的消息内容做哈希/去重（messageId + 规范化正文），噪音直接消失；如果确实有语义编辑，才需要走更新语义。对 Codex rollout（append-only JSONL 被原地重编码）来说，前者是大概率——这也意味着「旧消息 skip-if-exists、只导新增」默认就是对的，真正编辑过的历史消息是否需要刷新记忆，可以做成显式的更新通道而不是整场重放。

[hijzy]

Hi, thanks for the detailed report. This is related to the idempotency conflicts described in #369, but it involves a different code path: Codex session rewrites cause previously imported turns to be replayed with changed request bodies.
PR #464 addresses the Skill-specific variant, while this conversation replay case still requires a separate fix. PR #393 explored migrating stale idempotency keys, but it has not been merged yet.
We’ll keep this issue open and continue working on a proper fix for Codex session replay and scan watermark recovery.