| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| admin | ||
| ai | ||
| assistant | ||
| auth | ||
| clinical-gap | ||
| clinical-signals | ||
| facts | ||
| mcp | ||
| patient | ||
| persona | ||
| plan | ||
| plan-aggregate | ||
| realtime-coach | ||
| sync | ||
| weixin-aibot |
测试服定向补数(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 |
|---|---|---|
| .. | ||
| admin | Loading commit data... | |
| ai | Loading commit data... | |
| assistant | Loading commit data... | |
| auth | Loading commit data... | |
| clinical-gap | Loading commit data... | |
| clinical-signals | Loading commit data... | |
| facts | Loading commit data... | |
| mcp | Loading commit data... | |
| patient | Loading commit data... | |
| persona | Loading commit data... | |
| plan | Loading commit data... | |
| plan-aggregate | Loading commit data... | |
| realtime-coach | Loading commit data... | |
| sync | Loading commit data... | |
| weixin-aibot | Loading commit data... |