Skip to content

fix: make recall resilient to transient database contention - #72

Closed
Liyuk wants to merge 2 commits into
adoresever:mainfrom
Liyuk:fix/recall-reliability
Closed

Liyuk wants to merge 2 commits into
adoresever:mainfrom
Liyuk:fix/recall-reliability

Conversation

@Liyuk

@Liyuk Liyuk commented Aug 17, 2026 •

Copy link
Copy Markdown

What

Configure PRAGMA busy_timeout = 5000 in openDb so concurrent processes sharing the same SQLite file wait briefly for transient write locks instead of failing immediately with SQLITE_BUSY.

The earlier DSH recall-cache portion of this PR is no longer applicable after the upstream recall pipeline was refactored, so this update keeps the database reliability fix and its regression coverage only.

Coverage

  • Verify every opened connection has a 5000 ms busy timeout.
  • Verify a write succeeds after a separate process releases its SQLite lock.

The current PR branch is updated against the latest main. CI should run the regression tests.

Liyuk added 2 commits August 17, 2026 07:14
Two related reliability fixes for the graph-memory:recall context DSH
injects on every prompt assembly:

- src/store/db.ts: configure PRAGMA busy_timeout = 5000 in openDb so a
  write that collides with another connection's transaction (e.g. a second
  DSH process sharing ~/.dsh/graph-memory/graph-memory.db) waits for the
  lock instead of failing instantly with SQLITE_BUSY ("database is locked").
- dsh.ts: evict a recall from recallCache when it fails. Previously the
  rejected Promise stayed pinned, so every subsequent system-prompt/assemble
  re-awaited it and logged "[graph-memory] DSH recall failed" on each round
  until the next agent/inbox/claimed cleared it - a single transient error
  became a per-round failure.

Adds regression tests: busy_timeout is configured on every connection plus
a cross-process write-wait test, and the recall cache is evicted on failure
while successful recalls stay cached.
@adoresever

Copy link
Copy Markdown
Owner

感谢 @Liyuk 提交并持续更新这个修复,也感谢提供独立进程写锁的回归思路。

这个问题已经在 main / v1.6.0-beta.17 覆盖:数据库所有入口共用可配置的 dbBusyTimeoutMs,默认 5000 ms;锁等待在 journal 配置和迁移之前设置,初始化失败会关闭连接;DSH/OpenClaw 的配置以及提交的 dist 同步更新。独立 SQLite 连接持锁的回归验证通过,修复的是锁争用,不是增加模型重试。

本次审查还直接加载了 PR 提交的 dist/src/store/db.js,其 busy_timeout 仍为 0;主线发布包已为 5000。以后提交这类修复,请一起更新编译产物,确保 GitHub 直装加载的运行代码也包含改动。

因此按“已由主线覆盖”关闭本 PR,不是将此 PR 标记为已合并。感谢你定位并推动这个可靠性问题!如最新 main 上还有未覆盖的争用场景,欢迎另提最小复现或新 PR。

主线修复 · 版本维护说明

@adoresever adoresever closed this Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants