fix: bolt optimization push node kind filtering to sqlite in keyword fallback search - #1021
Conversation
…fallback search Co-authored-by: n24q02m <135627235+n24q02m@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
What
Optimized the
semantic_search_nodeskeyword fallback logic to push thekindfiltering down to the SQLitesearch_nodesquery.Why
Previously,
store.search_nodeswas called without thekindparameter, meaning all matched nodes were materialized into Python memory, and then filtered bykind. If the initial result set (constrained bylimit * 2) was saturated with nodes of the wrong kind, the subsequent Python-side filtering could result in truncating valid matches, returning far fewer results (or zero).Impact
Measurement
kindparameter is now passed directly into the query, applying theAND kind = ?(via the existing_kind_filter) logic in SQLite before returning limited rows.uv run pytest) and linters (uv run ruff check) still pass cleanly.PR created automatically by Jules for task 6804011392438315513 started by @n24q02m