[jia030928]

描述

点击“修复缺失/错维”后，原实现可能重新入队已有向量的记忆、清空正在执行任务的租约，留下无人认领的 in_progress。此外，历史失败任务即使已通过后续任务修复，仍会计入失败数，导致界面与实际进度不一致。

修复后按当前模型、维度及当前内容的未完成工作判断是否需要修复；保留有效租约，自动回收残留任务，并区分真实队列占用和已解决的历史失败。

定位

• 页面发送 mode: "repair"，服务端未传递该参数，直接调用无参数 rebuildEmbeddings()，导致全量入队。
• 去重冲突更新无条件清空 claimed_by、lease_until，却保留 in_progress；调度遗漏空租约任务，空闲时缺少独立检查。
• 页面与适配器将异步入队数量当作分批计算完成结果。
• 统计直接累加历史 dead_letter，未检查后续成功任务；仅按维度判断可用，也会遗漏同维度旧模型以及保留旧向量但当前内容处理失败的情况。

修改

• 传递并校验 repair/rebuild。修复模式检查对应向量（包括 L1 的摘要、动作向量），全量重建模式重新入队可处理的记忆。
• 通过当前模型实际输出确定维度，合并并发探测并缓存；模型配置变化后重新探测，探测失败时保留队列状态和错误提示。
• 重复入队保留有效租约和执行状态；无主、空租约或过期任务可重新领取。Worker 空闲时默认每 30 秒检查，关闭后停止轮询。
• 普通记忆和当前用户记忆采用相同的当前失败判定：历史失败行保留，只有当前内容已有后续成功任务且向量符合当前模型/维度时，才从当前失败数中排除。同一目标/向量字段的失败去重统计，其他未修复目标继续显示失败。
• 待处理、处理中和租约失效任务按实际队列行统计，即使内容已变化也不提前隐藏。
• 当前内容存在未完成工作、旧向量仍保留时，修复入口和可用数量使用同一判断，避免“失败 1、待修复 0、无法修复”。分别使用 dimMismatch、modelMismatch、contentMismatch 表示维度、模型及内容不匹配，页面同步展示。
• 页面每次点击只提交一次请求，随后按 runId 查询累计完成、失败及待处理进度；同时每 5 秒刷新实际队列状态，不把入队数量当作完成数量。
• 合并上游向量维护协调器，保留模型来源记录、动作向量维护及一次性升级修复，并接入本次有效租约保护、残留回收和当前失败统计。

测试

回归覆盖

• 63 条记忆、60 条已有向量、3 条缺失：仅入队 3 条；重复修复不重新入队已完成目标。
• 有效租约保护；无主/空租约/过期任务回收；旧持有者不能完成已重新认领的任务；空闲轮询与关闭停止。
• 两条用户记忆各真实执行 6 次受控模型失败，恢复后逐条修复，失败数 2 → 1 → 0，历史 dead_letter 保留；HTTP 维护接口和页面自动刷新一致。
• 普通记忆两张队表失败去重；当前模型变更、内容变化、向量丢失、其他目标仍失败等边界。
• 普通/用户记忆保留旧向量、新内容连续失败 6 次后，修复仍可入队；成功后再次修复入队 0 条。
• 内容变化后 pending/active/stale 仍可见；页面在内容失效但无缺失向量时允许点击修复，完成后禁用按钮。

合并后自动化检查

已通过 merge 同步 upstream/v1.2.6（98f36650），冲突整合提交为 aae81ed7。本轮另有 51 项定向回归通过，覆盖维护进度、维度探测、当前内容失效和队列恢复。

检查	结果
npm run memory:test	1702 通过，1 跳过
npm run lint	通过
npm run typecheck	通过
npm run test:packaging-guards	129 通过，1 跳过
npm run test:release-workflow	31 通过，5 跳过
git diff --check upstream/v1.2.6...HEAD	通过

此前安装包测试（2026-10-27，提交 8e8f9995）

以下安装包验证针对此前提交；本次冲突整合提交 aae81ed7 已通过上述自动化检查，尚未重新生成 DMG。

• npm run package:mac:arm64:cn:unsigned 成功，Desktop 1.2.4 / Memory 2.1.7；hdiutil verify 通过。
• 从新 DMG 提取应用，包内 227 个代码及页面文件与本次构建一致；运行时 buildId 为 58b04d7ca32a5d971c713f54251c3a089697ea541302898d9de8bae1f16765de。
• 使用包内实际 Memory、Electron Node 与 SQLite，独立数据库验证 63/60/3 修复、两类记忆失败恢复、有效租约及空租约回收。
• 实际启动安装包，在测试窗口加载包内 Viewer 并连接独立包内 Memory 测试服务，点击“修复缺失/错维”：HTTP 202、入队 1 条；完成后可用 1/1、待修复 0、失败 0，历史失败行保留。
• 两次启动健康检查通过、正常退出码均为 0；重启后合成测试数据保留。未覆盖旧版本真实用户数据升级。

失败/恢复测试使用可控本地嵌入替身，未覆盖真实远程模型服务。DMG 背景图替换仍有非阻断白边提示，完整性及运行验证通过。

[origami-chen]

用户记忆修复成功后，队列仍显示旧任务失败

问题
当一条用户记忆的向量任务连续失败、达到重试上限后，恢复模型并点击「修复缺失/错维」，新任务能成功生成向量，但页面仍显示「失败 1」。本轮用独立数据库及模型替身实际执行六次失败、修复、再次执行任务，得到 ready=1、needsRepair=0，同时 retryQueue.failed=1；页面组件验证也确认这两种状态会同时显示，修复按钮已禁用。用户无法从当前队列判断还有没有需要处理的失败。

原因
用户记忆维护通过 enqueueEmbeddingMaintenance → enqueueJob → getActiveJobByDedupeKey 入队。去重查询只复用 queued、leased、failed 状态；达到上限的 dead_letter（不再自动重试的失败记录）被保留，新修复另建一条任务。新任务成功不会改变旧记录，而这里无条件统计全部历史 dead_letter，再经 maintenance 接口交给页面作为当前失败数。保留旧任务的行为在指定 base 已存在；把已被成功修复覆盖的旧失败加入当前队列显示，是本次新增统计的问题。

建议做法
为维护页面统一按“当前记忆内容和目标向量仍未完成的工作”计算队列状态。保留历史失败记录，但当同一目标的后续任务已经成功满足当前内容及模型要求时，不再计入当前失败数；普通记忆重试队列和用户记忆任务应采用同一规则。同步核对维护入队、成功处理、统计接口和页面，并补充“失败达到上限→恢复模型→修复成功→当前失败归零”的完整测试；仍未修复的其他目标必须继续显示失败。