AskaEth
b4bdaef9ba
fix: 健康检查探库超时 5s → 1s（Console 探活超时只有 2500ms）
上一版把探库超时写成 5s，比 Console 的探活超时（console/main/service.js:389
的 timeout: 2500）还长。数据库是单连接，备份 VACUUM INTO 或整包重算占住连接时，
探针会等满 5s，于是整个 /api/health 请求超时，Console 把服务标成「未就绪」——
状态灯变红、托盘提示异常，console/main/index.js:671 在未就绪时还会跳过大屏重排。
为了「避免误判健康」加的探库，反而制造了另一种误判。
- healthProbeTimeout 5s → 1s：正常 SELECT 1 是亚毫秒，走满超时只可能是连接被占。
- probeDatabases 返回三态 ok / busy / error：busy 表示超时前没拿到连接（未必是故障，
多半是备份或重算占着），error 才是真报错，两者分的错因不同，别混成一句话。
- 新增 TestHealthProbeStaysBoundedWhenDatabaseBusy：用事务占住赛事库唯一连接，
断言 /api/health 仍回 200、db:"busy"、耗时 < 2000ms（这个数就是挡住超时被调回 2.5s 以上的护栏）。
- 更正一处写错的理由：状态码保持 200 与「避免重启循环」无关——setHealthy(false)
只改状态与 UI，重启只发生在进程真的退出时（service.js 的 handleExit）。真正理由是
前端 health() 见到 ok:false 会抛错，「关于」页会显示「未知（/api/health 不可达）」，
一次数据库抖动不该让界面宣称版本未知。
版本号 dev_0.1.2 → dev_0.1.3。
2026-09-11 14:42:57 +08:00
..
2026-09-11 14:42:57 +08:00
2026-09-11 04:05:02 +08:00
2026-09-10 17:45:11 +08:00
2026-09-09 18:47:34 +08:00
2026-09-10 09:47:06 +08:00
2026-09-11 04:05:02 +08:00
2026-09-10 09:47:06 +08:00