派生数据只在写入时入队,旧数据要单独回填

**embedding / 索引 / 摘要这类派生数据,如果入队只挂在「新建」或「标题正文更新」事件上,那么存量数据永远不会被处理,失败任务也不会自动复活。** 此时「查不到/搜不出来」不是检索层坏了,是数据层从来没被喂过。

实测形态:45 条笔记 40 条从未入队

旧笔记:      从未创建过 embedding run(没有 backfill 机制)
失败笔记:    停在 failed,不会自动 retry
同版本再保存: 用同一个幂等键,不会重新创建任务

而执行器本身是好的——当天新订阅的文章已成功生成 gemini-embedding-001 / 768维 向量。所以主因是缺少历史补跑 + 失败恢复,不是 worker、数据库或 cron 又断了。

可迁移的判断

设计任何「写入时触发的派生数据」时,必须同时回答三问:

  1. 存量怎么办? 上线这条派生逻辑之前已经存在的数据,谁把它们跑一遍(backfill / 迁移)?
  2. 失败怎么办? 失败任务有没有重试或复活入口?部署新配置后,旧的 failed 任务会不会自动重跑?
  3. 同一输入重复保存会不会重新入队? 幂等键在防重复的同时,也可能挡住「想重试」的那一次。

三问里任何一问没答案,这类功能上线后就一定会出现「新数据正常、老数据永久缺失」的静默缺口。

相关

  • 存量不会自动跟上新逻辑 —— 本条是该 synthesis 的一处实例:新逻辑只对未来经过该路径的对象生效
  • 异步补齐长期不生效要查写入失败 —— 那页查「写不进去」,本条查「从来没入队 / 不重试」
  • INSERT OR IGNORE会让旧行不更新 —— 同形:新逻辑修对了,旧行被跳过
  • 知识库先编译再查而不是查询时拼原文
  • 活的能力取决于增量机制而不是生成质量 —— 本条是该 synthesis 的一处证据:缺的是「触发 / 存量 / 失效」三问里的存量与重试