mountain 890b520b1c fix(sqlite): make concurrent indexing writes robust (no "database is locked") ... Real concurrency e2e (8 threads adding the same file) surfaced a bug the mocked unit tests missed: concurrent add_document calls failed with sqlite3.OperationalError "database is locked". Root cause — under WAL the dedup SELECT (find_document_by_hash) left a read snapshot on the connection, and the subsequent INSERT on that stale snapshot raised SQLITE_BUSY_SNAPSHOT, which busy_timeout does not retry. Fixes: - open connections in autocommit (isolation_level=None) so a SELECT never leaves a lingering read snapshot and each write is its own transaction - PRAGMA busy_timeout=10000 so concurrent writers wait for the WAL single-writer lock instead of failing immediately - an instance-level write lock serializing the fast write methods within the process (the expensive LLM indexing stays parallel) Now 8 concurrent adds of one file -> a single doc_id, zero errors. Adds a real-thread regression test. Claude-Session: https://claude.ai/code/session_01Kx5DgKbhK1N8autqXH8SmS		2026-07-07 18:23:01 +08:00
..
__init__.py	feat: add PageIndex SDK with local/cloud dual-mode support (#207)	2026-04-08 20:21:58 +08:00
protocol.py	feat: add PageIndex SDK with local/cloud dual-mode support (#207)	2026-04-08 20:21:58 +08:00
sqlite.py	fix(sqlite): make concurrent indexing writes robust (no "database is locked")	2026-07-07 18:23:01 +08:00