AskaEth
b4bdaef9ba
上一版把探库超时写成 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。
2 lines
10 B
Plaintext
2 lines
10 B
Plaintext
dev_0.1.3
|