| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| adapters | ||
| assembler | ||
| cold-import | ||
| dto | ||
| pipeline | ||
| pull | ||
| push | ||
| reconcile | ||
| transforms | ||
| sync.controller.ts | ||
| sync.module.ts | ||
| sync.service.ts |
测试服实测(第二轮增量):cohort 列出 15,107 人,其中「复杂病例变了但人没来诊」的 19 人确实被 UNION 分支正确带进了 cohort,但他们的 host_follow_up_active 始终没更新。 根因在 loadTablesForCohort:主档 query 同时被注入 cursor 和 cohort 过滤 → WHERE last_visit_time > '2026-07-30 09:36' AND (patient_id,brand) IN (<本批 tuples>) 这些人末次就诊在几个月前 → 被 cursor 挡掉 → 主档整轮拉不到 → 不 upsert。 batch 日志早有征兆:cohort 726 人,fact_client_out 只回 675 行。 cohort 已经是比 cursor 更强的限定(它就是"本轮要处理哪些患者"的答案), 主档再叠 cursor 是多余且有害的。非 cohort 模式靠 reversePullPatientMaster 兜这个场景, cohort 模式此前无兜底 —— 与其再补一次反向拉,不如从源头去掉这个条件。⚠ ️ 这是**既有缺陷**,不是本次接入引入的:任何"事实变了但 last_visit_time 没变"的患者 (EMR 补写、预约改期),其主档在 cohort 模式下本来就整轮不更新。此前只表现为主档字段 偶尔陈旧、被 stub 兜住不易察觉;到了派生列(主档不拉 = 列不重算)才致命。 cursorAdvances 不受影响:bundle 水位写的是 run_start baseline,不取 max。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| adapters | Loading commit data... | |
| assembler | Loading commit data... | |
| cold-import | Loading commit data... | |
| dto | Loading commit data... | |
| pipeline | Loading commit data... | |
| pull | Loading commit data... | |
| push | Loading commit data... | |
| reconcile | Loading commit data... | |
| transforms | Loading commit data... | |
| sync.controller.ts | Loading commit data... | |
| sync.module.ts | Loading commit data... | |
| sync.service.ts | Loading commit data... |