| | |
|---|
| | | 的回退在途）状态。以后新写这类「后台任务只处理了我这条」的用例，照它的做法先腾窗口，不要再依赖测试库的 |
|---|
| | | 累积状况。 |
|---|
| | | |
|---|
| | | ## 「Too many connections」：也是环境相关，已修（2026-10-12） |
|---|
| | | |
|---|
| | | 全量跑着跑着，**后加载**的那个用例类会整类报错，根因是： |
|---|
| | | |
|---|
| | | ``` |
|---|
| | | Unable to obtain connection from database: ... |
|---|
| | | message from server: "Too many connections" (SQL State 08004) |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 每个 `@SpringBootTest` 的上下文都缓存到整个 JVM 结束、各自持有一个 Hikari 连接池，而 Hikari 的 |
|---|
| | | `minimum-idle` 默认等于 `maximum-pool-size`（10），**启动时就把 10 条连接建满**。一次全量会累积十几个 |
|---|
| | | 上下文（2026-10-12 实测 15 个），150 条空闲连接正好把测试库那个 8.0 实例的 `max_connections=151` |
|---|
| | | 吃光。测试 profile 现在把 `spring.datasource.hikari.minimum-idle` 钉成 `1`（见 |
|---|
| | | `src/test/resources/application-test.yml`），空闲上下文只留一条、按需再涨，连接池语义不变。 |
|---|
| | | **别把它改回去**：症状是「明明只加了几个测试，却有整整一个类的用例全挂」，很容易被误判成自己引入的回归。 |
|---|
| | | |
|---|
| | | 判断依据：报错里出现 `Too many connections` 就是它，与代码无关（同一次全量里，挂的总是**靠后**加载的 |
|---|
| | | 上下文，而不是某个具体用例的逻辑）。 |
|---|
| | | |
|---|
| | | ## 测试库跑不起来时，先看 WSL（2026-09-17 实测） |
|---|
| | | |
|---|
| | | 测试库那个 8.0.36 实例跑在 **WSL 的 docker 里**（发行版 `Ubuntu-26.04`，容器 `talent-card-mysql-1`， |
|---|
