| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| cli | ||
| common | ||
| config | ||
| modules | ||
| openapi | ||
| prisma | ||
| queues | ||
| redis | ||
| types | ||
| app.module.ts | ||
| health.controller.ts | ||
| instrument.ts | ||
| main.ts |
测试服定向补数(PAC_COHORT_ONLY_PATIENT=@file,70,283 个 id)实跑 fatal: Syntax error: failed at position 262142 262142 = 256 KiB,ClickHouse max_query_size 默认上限。7 万 id 拼 IN (...) 约 630KB, 超 2.4 倍;重试 3 次全败,patients upserted: 0(没写坏任何数据)。⚠ ️ 这与 resolveOnlyPatientIds 的 `@file` 是**两个不同的上限**,之前混为一谈了: · @file 解的是环境变量 128KB(E2BIG)—— 传参侧 · 本次是 SQL 文本长度 —— 服务端解析侧 文件读进来了,SQL 照样超。注释里"大名单走文件"的承诺此前并不成立。 改为按 10k 分片跑(≈90KB/片,离上限有充足余量),其余条件(cursor / clinics / union 分支) 每片原样带上,结果用 Map 按 (key, tenant) 去重合并 —— 与单条 SQL 的结果集等价。 名单未超阈值时仍走单条 SQL,行为不变。 分片时不套 orderTail 的 LIMIT:PAC_COHORT_LIMIT 采样与分片叠加会"每片各取 N"而超量, 且定向重摄本就是显式点名,不该再被采样截断。 补 3 项回归(含"7 万单条必超上限"的反证),共 18 项。 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... |