[D-01][medium] 写队列 busy 状态一旦置位就永不恢复，/readyz 永久返回 503 #27

New Issue

2026-09-30T13:56:56+08:00

nixevol commented

2026-09-30 13:56:56 +08:00

编号：D-01　严重级：medium　工作线：存储、配置、命令行与部署（internal/store、internal/config、cmd/nixmsg 命令、deploy）　来源：审查 P-13
依赖：无　被依赖：无

结论与统一方案

采用审查 P-13 的方案：runBatch 提交成功后，在锁内把 ready 置回 true、清掉 lastWriteErr。担心抖动时可要求最近 30 秒内没有失败才恢复。现状是一次短暂故障（busy_timeout 内拿不到写锁、磁盘瞬时出错）之后，/readyz 一直到重启都返回 503。

改动文件

internal/store/queue.go。

与其他问题的交互 / 冲突说明

与 D-02 同文件，存储线内顺序合入。

验收与测试

先调 markBusy，再成功执行一次 Do，IsReady() 为 true。

问题明细（各区审查原文，证据含文件与行号）

以下是本次复审各区审查报告的原文段落。A、M、I、P、S 开头的是原始发现编号（A 管理后台与网页、M 消息核心、I 身份认证群在线、P 传输平台部署、S SDK）。解决方案以本 issue 上方的"结论与统一方案"为准；原文里的方案与之不一致时，按上方执行。

[P-13] 写队列 busy 状态一旦置位就永不恢复，/readyz 永久返回 503

严重级：medium
分类：逻辑
现象与影响：
- Begin、SAVEPOINT、ROLLBACK TO、RELEASE、Commit 任何一步失败，markBusy 都会把 ready 置为 false，之后没有任何地方把它改回 true。
- 一次短暂故障（5 秒 busy_timeout 内拿不到写锁、磁盘瞬时出错）之后，/readyz 一直到重启都返回 503。
证据：store/queue.go:248-260、225-245；ready.go:19-24。
文档依据：DEVELOPMENT 4.3「/readyz 已能读写数据库」、7.8。
为何不是故意设计：DEVIATIONS P2 第 1 条只说失败时 IsReady()=false，没说是永久的。
解决方案：runBatch 提交成功后，在锁内把 ready 置回 true、清掉 lastWriteErr。如果担心抖动，可以要求最近 30 秒内没有失败才恢复。
改动文件：internal/store/queue.go
与其他模块的交互/冲突风险：无。
需补测试：先调 markBusy，再成功执行一次 Do，IsReady() 为 true。
置信度：代码阅读确定

_{复审基线：main 4059a15（2026-09-30）。编号说明、各工作线的合并顺序、共享文件归属见总览 #7。}

**编号**：D-01　**严重级**：medium　**工作线**：存储、配置、命令行与部署（internal/store、internal/config、cmd/nixmsg 命令、deploy）　**来源**：审查 P-13 **依赖**：无　**被依赖**：无 ### 结论与统一方案采用审查 P-13 的方案：`runBatch` 提交成功后，在锁内把 `ready` 置回 true、清掉 `lastWriteErr`。担心抖动时可要求最近 30 秒内没有失败才恢复。现状是一次短暂故障（busy_timeout 内拿不到写锁、磁盘瞬时出错）之后，`/readyz` 一直到重启都返回 503。 ### 改动文件 `internal/store/queue.go`。 ### 与其他问题的交互 / 冲突说明与 D-02 同文件，存储线内顺序合入。 ### 验收与测试先调 `markBusy`，再成功执行一次 `Do`，`IsReady()` 为 true。 --- ### 问题明细（各区审查原文，证据含文件与行号） > 以下是本次复审各区审查报告的原文段落。A、M、I、P、S 开头的是原始发现编号（A 管理后台与网页、M 消息核心、I 身份认证群在线、P 传输平台部署、S SDK）。**解决方案以本 issue 上方的"结论与统一方案"为准**；原文里的方案与之不一致时，按上方执行。 #### [P-13] 写队列 busy 状态一旦置位就永不恢复，/readyz 永久返回 503 - **严重级**：medium - **分类**：逻辑 - **现象与影响**： - Begin、SAVEPOINT、ROLLBACK TO、RELEASE、Commit 任何一步失败，`markBusy` 都会把 `ready` 置为 false，之后没有任何地方把它改回 true。 - 一次短暂故障（5 秒 busy_timeout 内拿不到写锁、磁盘瞬时出错）之后，`/readyz` 一直到重启都返回 503。 - **证据**：`store/queue.go:248-260`、`225-245`；`ready.go:19-24`。 - **文档依据**：DEVELOPMENT 4.3「/readyz 已能读写数据库」、7.8。 - **为何不是故意设计**：DEVIATIONS P2 第 1 条只说失败时 `IsReady()=false`，没说是永久的。 - **解决方案**：`runBatch` 提交成功后，在锁内把 `ready` 置回 true、清掉 `lastWriteErr`。如果担心抖动，可以要求最近 30 秒内没有失败才恢复。 - **改动文件**：`internal/store/queue.go` - **与其他模块的交互/冲突风险**：无。 - **需补测试**：先调 `markBusy`，再成功执行一次 `Do`，`IsReady()` 为 true。 - **置信度**：代码阅读确定 --- <sub>复审基线：main `4059a15`（2026-09-30）。编号说明、各工作线的合并顺序、共享文件归属见总览 #7。</sub>