Skip to content

fix: wait out SQLite busy on concurrent asset upserts - #329

Open
OrdinarySF wants to merge 1 commit into
AIPentest:mainfrom
OrdinarySF:fix/sqlite-asset-busy-lock
Open

OrdinarySF wants to merge 1 commit into
AIPentest:mainfrom
OrdinarySF:fix/sqlite-asset-busy-lock

Conversation

@OrdinarySF

Copy link
Copy Markdown

Summary

Fixes #328

Deep mode fires many create_asset calls in the same turn. Those writes hit SQLite database is locked in 4–26ms, so _busy_timeout=5000 never actually waited.

This is not a missing pool. configureDBPool already sets MaxOpenConns=25. SQLite still allows only one writer. UpsertAssets uses a DEFERRED transaction (SELECT then INSERT). Parallel deferred txs deadlock on the write upgrade and SQLite returns SQLITE_BUSY immediately.

Changes

  • Open SQLite with _txlock=immediate and _busy_timeout=30000
  • Drop the pool from 25/5 to 8/4 (WAL still has concurrent readers; 25 write connections made lock storms worse)
  • Retry UpsertAssets a few times on database is locked
  • Shared sqliteOpenDSN() for conversations and knowledge DBs

Test plan

  • TestUpsertAssetsConcurrentDoesNotReturnLocked — 32 goroutines upsert distinct hosts
  • go test ./internal/database -run 'Asset|Upsert'
  • Existing asset tests still pass

Deep mode fires many create_asset calls at once. UpsertAssets used a
DEFERRED transaction (SELECT then INSERT) on a 25-connection pool, so
writers hit SQLITE_BUSY immediately and returned "database is locked"
in a few milliseconds instead of waiting.

Open SQLite with _txlock=immediate and a 30s busy timeout, shrink the
pool, and retry locked upserts. Add a 32-way concurrent upsert test.
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.

Deep 并行 create_asset 报 database is locked,5ms 即失败

1 participant