[harshitaajoshi]

Fixes #2386

What does this PR do?

In query (BM25) mode, search_graph applied the label filter after the 2000 row FTS5 candidate window. When a token is common but the requested label is rare among its matches, those rows fell outside the window and the call returned 0 rows while reporting a saturated window.

This PR moves the label into candidate selection, as suggested in the issue:

• When label is set, the MATCH expression becomes (<tokens>) AND label : "<Label>", so the window is filled with rows of that label. The outer n.label = ? check stays as the exact filter (FTS5 matching is case insensitive, so the column filter is only a superset pre-filter).
• The ranked query, the count query and the saturation probe share the same MATCH string, so total, total_relation and candidate_window_saturated describe the label scoped window. A rare label no longer gets a false gte.
• Only a plain identifier label ([A-Za-z0-9_], up to 64 chars) is spliced in, as a quoted FTS5 string. Anything else keeps the previous unscoped MATCH, so a label can never inject FTS5 syntax.

Ranking stays the same

The added label : "..." phrase is itself scored by bm25(), and its contribution depends on row length, so on its own it can reorder near ties. To avoid that, the label column weight in BM25_WEIGHTS is now a bound parameter: 1.0 as before, 0.0 when the MATCH is scoped. Every candidate carries the label in that case, so a label hit cannot distinguish them anyway.

I checked this on an index of this repo's src/ (6.9k nodes) by running the ranked SQL old vs new for 20 common tokens across every label with results (75 pairs):

Variant	Same result set	Same top 10 order
Label phrase, weight 1.0	75 / 75	73 / 75
Label phrase, weight 0.0 (this PR)	75 / 75	75 / 75

The one intended difference: when a query token is the label word itself (for example query=function label=Function), that token's label column hit no longer scores, since all candidates share it.

Tests

• tool_search_graph_bm25_label_filter_selects_candidate_window: 2001 Functions and 3 lower ranked Classes share a token. label=Class must return all 3 with total:3, total_relation:eq and no saturation flag; label=Function must still report a saturated window; a label containing FTS5 syntax must stay in BM25 mode and return 0 rows. Fails on current main (0 Classes returned).
• tool_search_graph_bm25_label_scope_keeps_rank_order: a label filtered query lists its rows in the same relative order as the unfiltered query. Fails if the label weight is left at 1.0.

Local run after rebasing on current main: full suite 9646 passed, 11 skipped. lint-ci passes apart from one cppcheck constParameterCallback note in src/daemon/application.c, which is already on main and not touched here.

Checklist

• Every commit is signed off (git commit -s)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci), plus lint-tidy-diff clean on the changed lines
• New behavior is covered by a test (reproduce-first for bug fixes)

Written with the help of Claude Code. I reviewed and ran everything above myself.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Thanks for the BM25 label-window fix and the ranking comparison. I have read the exact-filter and saturation details; this remains pending review, including the documented label-word scoring difference.

[DeusData]

Thank you @harshitaajoshi -- this is a careful fix, and it is exactly the approach #2386 asked for. Keeping the exact n.label = ? check so the MATCH is only a superset pre-filter, sharing one MATCH string between the ranked query, the count and the saturation probe, and neutralizing the scored label : "..." phrase with the bound weight (with a test that fails at 1.0) are the details that make it safe to merge.

While re-checking it on real indexes we found one more way a labelled query in BM25 mode came back empty. Your label-scoped window is what makes that fixable, so we pushed two small commits on top of your branch (your commit is untouched):

1. A merge of current main. The branch was 246 commits behind; there were no conflicts, and this lets CI run against today's tree.

2. fix(mcp): serve every named label in BM25 search_graph, never a silent zero

   • label=File, Folder, Variable and Project still returned 0 rows in query mode, often with total_relation: "eq", although those nodes are in nodes_fts and match the query. The cause was the noise exclusion meant for unlabelled queries (n.label NOT IN ('File','Folder','Variable','Project')), which also applied when the caller named one of these labels. It now applies only when no label is given (one shared SQL fragment for the ranked and the count query), so such a label gets its own label-scoped window like any other label. Unlabelled queries are unchanged.
   • A label that no node carries as spelled (labels are case-sensitive, e.g. label=class) still returns 0 rows, as structural search does, but no longer silently: the result carries a hint naming the stored spelling, or pointing to get_graph_schema when the label is unknown. An existing label with no matching row stays a plain zero.
   • Two tests in the mcp suite: one query per excluded label plus the unlabelled case, and one for the hint. Both fail on the branch without the change.

What we measured on Django, meilisearch and kubernetes indexes, comparing your head (merged with main) against the fix-up:

• Labelled queries that returned 0 rows although matching nodes exist: 18 -> 0 (of 81 label queries), 21 -> 0 (of 114) and 21 -> 0 (of 130). The four labels now return 704, 581 and 716 rows across those queries.
• Every other label: byte-identical results to your head. Unlabelled queries: byte-identical to main.
• The graph itself is unchanged; this is a search-only change.

The same window effect also hits file_pattern, kind and namespace, which filter after the window and cannot go into the MATCH the way the label does. That is outside this PR's label scope, so we will handle it in a separate follow-up PR.

Thanks again for the reproduction test and the ranking comparison -- they made this review easy.

[harshitaajoshi]

Thanks a lot for the review and for the follow-up commits. Making the noise exclusion apply only to unlabelled queries makes sense, and the hint for a misspelled label is a nice touch.

[DeusData]

Thank you for the BM25 label-window fix and the follow-up discussion. I merged current main into the branch in fc18b9da0 to pick up the shared CI fixes. The combined-tree check preserved the reviewed patch and its surrounding context, with only line positions moving. Fresh GitHub CI will validate this head; the separately agreed post-window filter follow-up remains separate.

[DeusData]

Thank you again for the BM25 label-window fix. Our October updates record the additional named-label handling and baseline refresh as completed, so no repeat contributor work is requested. Sorry for the delay in the remaining maintainer follow-up—I’ll follow up soon.

[DeusData]

Thank you again, @harshitaajoshi. We merged current main into the branch (one signed-off merge commit, 760cb9c; your commits are unchanged) so CI validates your fix against today's tree. The one red check on the previous run (the UI test job) failed while downloading a package during npm install, before any test ran, so it had nothing to do with your change. Nothing is needed from you; please pull before pushing again.