查上一条修复时,拿测试机做对照发现两件事: ① **`patient_return_visit` 少了个 s**(daily-health-report.service.ts:256)。 真实表名是 `patient_return_visits`(schema.prisma:455 的 @@map)。 报错被 pacPatientCount 的 try/catch 吞成 WARN + 返回 null → 日报照发, 只是「回访」那行长期没有 PAC 侧计数,静默缺了一项对账。 生产上看不到这个 WARN,因为它的日报根本没跑到这一步就先被连接池超时打死了 —— 一个 bug 把另一个 bug 遮住了。 ② **「测试服 URL 里显式 connection_limit=30,所以不受影响」是错的**,而这句话被 prisma.service.ts 的注释、测试文件的注释一路传下来,也是我判断"测试机不用验"的依据。 实测(`docker inspect`)两台容器里的 DATABASE_URL 都是 `postgresql://…@postgres:5432/pac?schema=public` —— **没有 connection_limit**: compose 的 environment: 段整条覆盖了 .env 里的值(.env.example 早就写了这条,只是没人联想到)。 佐证:测试机 09-01 的健康日报也报了同一句 `connection limit: 5`。 → 测试机跟生产是同一个池、同一个 bug,**这个修复在测试机验得出来**。 判断逃生口生不生效只能看容器实际环境变量,不能看 .env 文件;三处注释都已改口径。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| .claude | Loading commit data... | |
| .design-sync | Loading commit data... | |
| apps | Loading commit data... | |
| clickhouse/config.d | Loading commit data... | |
| deploy | Loading commit data... | |
| docs | Loading commit data... | |
| packages | Loading commit data... | |
| scripts | Loading commit data... | |
| .gitignore | Loading commit data... | |
| .gitlab-ci.yml | Loading commit data... | |
| .npmrc | Loading commit data... | |
| .prettierrc | Loading commit data... | |
| README.md | Loading commit data... | |
| docker-compose.expose.yml | Loading commit data... | |
| docker-compose.managed.yml | Loading commit data... | |
| docker-compose.prod.yml | Loading commit data... | |
| docker-compose.yml | Loading commit data... | |
| eslint.config.mjs | Loading commit data... | |
| liu.cjs | Loading commit data... | |
| package.json | Loading commit data... | |
| pnpm-lock.yaml | Loading commit data... | |
| pnpm-workspace.yaml | Loading commit data... | |
| tsconfig.base.json | Loading commit data... | |
| turbo.json | Loading commit data... |