杭州明婳科技
5eb3879a85
fix(database): H-db-1 ping 路径统一经 pingWithTimeout 3s 约束（M11 完整覆盖）
module 04 database 评审发现 H-db-1（HIGH）：M11 的 pingWithTimeout 只加到包级
HealthCheck()，未覆盖 4 条 ping 路径：
- (*Manager).HealthCheck（被后台探活 probeOnce master + /health 端点共用）
- probeOnce 从库 ping
- InitDB 启动 master ping
- InitDBWithReplicas 启动 replica ping
挂起 DB（连接活但不响应，区别于宕机的 connection-refused 快速失败）下，这些
路径的 sqlDB.PingContext(ctx) 用 rootCtx/Background（无 deadline）无限阻塞，
致：探活 goroutine 阻塞至 shutdown、#21 自愈冻结（replicaHealthy 停留旧值、
Replica() 可能路由到已死从库）、IsHealthy() 缓存失真、App.Init 启动卡死。
修复：4 路径统一改用 pingWithTimeout(sqlDB, ctx)，受 healthCheckTimeout(3s)
约束（context.WithTimeout 尊重 ctx 自带更短 deadline）。/health 端点随之收紧
到 3s（更快失败，非回归）；InitDB 5 次重试给足 15s+ 余量无误判。
回归测试 manager_hdb1_internal_test.go：注册 hungDriver（Conn.Ping 阻塞到 ctx
取消模拟挂起 DB），验证 pingWithTimeout / m.HealthCheck / probeOnce replica 三
路径在 Background ctx 下 ~3s 返回（修复前无限 hang）。go test -race ./database/
绿（含 3 条 ~3s 挂起用例）。
对抗复核（diff scan）：4 路径均 pingWithTimeout，defer cancel 无 ctx 泄漏，
无新缺陷。CHANGELOG 记录。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-09 19:14:04 +08:00
..
2026-07-08 21:02:21 +08:00
2026-07-08 21:25:18 +08:00
2026-07-09 19:14:04 +08:00
2026-07-08 21:25:18 +08:00
2026-07-09 19:14:04 +08:00
2026-07-08 19:11:37 +08:00
2026-07-07 00:19:19 +08:00
2026-07-08 18:48:41 +08:00
2026-07-08 19:11:37 +08:00
2026-07-03 23:16:03 +08:00
2026-07-09 12:54:52 +08:00
2026-07-09 12:54:52 +08:00