| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| cli | ||
| common | ||
| config | ||
| modules | ||
| openapi | ||
| prisma | ||
| queues | ||
| redis | ||
| types | ||
| app.module.ts | ||
| health.controller.ts | ||
| instrument.ts | ||
| main.ts |
同一情况三条路给了三个答案:
processSubject → ensurePatientStub(),照常落库
processPatientRelations → `if (!patientId) continue`,静默丢
processPatientReturnVisits → `if (!patientId) continue`,静默丢
那句 continue 的注释写着「非 active client,无处挂靠」,但 cold-import 的 cohort 路径
经 injectPatientFilter 对每张表都按患者 id 过滤、patients 又先跑,它几乎永不触发;
真正踩中的是 push —— 宿主先推 customer_referee_circle(07-27)、后推
customer_basic_info(07-28~29),10169 条关系边只落 257 条(2.5%),
且不计 failed、不进回执,宿主看到的是 accepted=N / failed=0,完全无从察觉。
契约文档承诺「推送顺序无要求」,兑现它靠的就是空壳兜底(pull 侧的等价物是
ClickHouseSourceService 的「反向拉主档」)。空壳只建**本人**这一侧;关系的对方
(relatedPatientId 可空)不建,靠 upsert 的 `update: { relatedPatientId }`
在对方入库后重推时回填 —— 那段回填代码本来就在。
加源码闸 ingest-patient-stub-consistency.spec.ts 锁住「三条路对齐」,
将来加第四个 process* 方法不至于再漏。已验证该闸对修复前的代码报
processPatientRelations / processPatientReturnVisits 各 1 处静默丢弃、
且两者都缺 ensurePatientStub。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| cli | Loading commit data... | |
| common | Loading commit data... | |
| config | Loading commit data... | |
| modules | Loading commit data... | |
| openapi | Loading commit data... | |
| prisma | Loading commit data... | |
| queues | Loading commit data... | |
| redis | Loading commit data... | |
| types | Loading commit data... | |
| app.module.ts | Loading commit data... | |
| health.controller.ts | Loading commit data... | |
| instrument.ts | Loading commit data... | |
| main.ts | Loading commit data... |