Move thread search SQLite reads off the serving loop - #13
Merged
Conversation
List and sidebar already used the readonly WAL worker. GET /threads/search still called searchThreadsWithPendingInteractionState on the serving connection, so a palette keystroke could stall streams. Same worker, new request name; :memory: stays sync.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human comments
What was wrong
List and sidebar already run SQLite reads on a readonly WAL worker (Datahazed/bb#4, get-bb/bb#2936).
GET /threads/searchstill calledsearchThreadsWithPendingInteractionStateon the serving connection. A command-palette keystroke could stall streams and other HTTP on the same Node loop. That is the leftover of get-bb/bb#1131 after the list/sidebar cut.What changed
searchThreadsWithPendingInteractionStateOffThreadon the same worker, new request name.asyncand awaits the off-thread result.:memory:(tests, no worker) stays on the serving connection.unknownso list and search can share the queue.No
HOST_DAEMON_PROTOCOL_VERSIONbump. Search response shape is unchanged.Why this way
Do not invent a second worker. Search is the same class of sync SQLite the list path already moved. Palette typing is the remaining user-facing stall on that connection.
Benefit to bb
Command palette / thread search no longer blocks agent streams or other HTTP while SQLite scans titles. Same product rule as #4: never block Node on sync SQLite for a read the WAL worker can own.
Harvest
Submit after get-bb get-bb#2936 so the worker exists. Copy this body onto a get-bb PR that targets a branch containing get-bb#2936, or stack.
How you verified
packages/db/test/sqlite-read-queue.test.ts: file-backed worker search matches the serving connection. 3 passed under Node 22 (/opt/homebrew/opt/node@22/bin, ABI 127 matching better-sqlite3).