Worker plandb calls can fail with SQLITE_BUSY while the run holds its store
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Read internal/plandb/persist.go:213 and internal/plandb/store.go:100, then run the deterministic lock-holding reproduction in internal/plandb. Check the open, show, and done paths, including the existing e2e and unit coverage. Done means read-only show works during a held write transaction, writes have bounded retry or explicit retryable behavior, and the manual and invalidates reflect changed wording.
由索引模型根据 Issue 内容生成。
描述
Found on santos/dev2 at 008363c98 (#1410). It reaches dev when #1410 merges.
What happened
On 2026-09-24, 16 worker trajectories in 11 of 34 conversations contained error: database is locked (5) (SQLITE_BUSY) from plandb calls, including plandb done. Read calls were among those affected. The store has a separate deferred read handle, but opening a CLI store also opens and initializes its immediate-lock write handle; a writer holding the file past the five-second busy timeout can make that opening fail.
Replication
Deterministic (no model). In internal/plandb, create a plan with Open, then use a second database/sql connection using the repository's modernc.org/sqlite driver and _txlock=immediate to hold a transaction for longer than five seconds. While held, open the same plan as the worker CLI does and run show or done. Today the open or command can return database is locked (5) (SQLITE_BUSY). Release the transaction and repeat as the control.
Field (real models). Run a multi-part /task on deepseek/deepseek-v4-flash with OPENROUTER_API_KEY; allow several minutes and a few cents. Inspect worker-visible plandb responses. The observed rate above came from one hand run, not a guaranteed reproduction rate.
Where
internal/plandb/persist.go:213, openDatabase, uses _txlock=immediate&_pragma=busy_timeout(5000); internal/plandb/store.go:100, Open, opens that handle before the deferred read handle.
The fix
Let read-only CLI operations open without taking a writer's lock. Serialize or retry writes for a bounded, explicit period and report a recoverable contention state without making a worker infer what happened.
Acceptance
- e2e: a worker
plandb showsucceeds while another handle holds a write transaction;doneeither succeeds after release or returns an explicit retryable result. - Unit: the lock-holding fixture covers open, read and write paths.
- Update the plandb manual and
invalidatesfor any changed retry wording.
- 主要语言
- Go
- 星标
- 115
- 派生
- 14
- 平均合并
- 9 小时 38 分钟
- 30 天内合并 PR
- 749
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
Agent-Field/CodeAF 的其他 Issue
-
area:chat feature
难度 2/5 1-3 小时 新手友好度 88/100
Agent-Field/CodeAF#1510 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
Agent-Field/CodeAF#1489 ·
维护者通常 1 天内回复
-
area:chat bug good first issue sev:papercut
难度 2/5 1-3 小时 新手友好度 78/100
Agent-Field/CodeAF#1470 ·
维护者通常 1 天内回复
-
area:chat bug good first issue sev:papercut
难度 2/5 1-3 小时 新手友好度 85/100
Agent-Field/CodeAF#1469 ·
维护者通常 1 天内回复
-
area:chat bug sev:papercut
难度 2/5 1-3 小时 新手友好度 88/100
Agent-Field/CodeAF#1468 ·
维护者通常 1 天内回复
查看 Agent-Field/CodeAF 的全部 Issue
相似的 Issue
-
enhancement low priority
难度 2/5 1-3 小时 新手友好度 85/100
eugenioenko/ttt#674 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 92/100
GoogleCloudPlatform/k8s-config-connector#13462 ·
维护者通常 1 天内回复
-
bug good first issue
难度 2/5 1-3 小时 新手友好度 85/100
vavallee/bindery#2793 · 1 条评论 ·
维护者通常 1 天内回复