search_graph: Route nodes have empty file_path, so label=Route + file_pattern always returns 0 — and the hint blames the label

Version

codebase-memory-mcp 0.9.0

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

Route nodes are indexed with an empty file_path, so any search_graph call combining label: "Route" with file_pattern matches nothing — and the returned hint blames the label, which is the one part of the query that was correct.

search_graph --project <slug> --label Route --file-pattern ".*league.*"

Actual:

{"total":0,"results":[],"has_more":false,
 "hint":"No nodes with this label. Available labels: Function, Method, Class, Interface, Route, Variable, Module, Package, File, Folder."}

The hint says "No nodes with this label" while listing Route among the available labels, and get_graph_schema reports 511 Route nodes in this project. Dropping file_pattern returns them immediately.

The cause is visible in any Route result — file_path is "":

{"name":"/api/mulligans/balance","qualified_name":"__route__GET__/api/mulligans/balance",
 "label":"Route","file_path":"","in_degree":1,"out_degree":0,"method":"GET"}

Route is the only label in the schema whose properties list includes file_path but which is populated with an empty string for every node. So file_pattern can never match a Route, and the combination is silently unsatisfiable rather than an error.

Expected, in order of preference:

Route nodes carry the file_path of the file that declares them, so file_pattern works as documented; or
the combination errors, or the hint says the filter excluded everything, rather than asserting the label is empty.

Why this matters

Scoping routes by file is the natural way to ask "what does this router expose?" on any repo with more than a handful of route files — and it is a plausible first query for an agent orienting in a backend. The wrong hint then sends you to debug the label (or conclude routes aren't indexed) when the label was fine.

There's a second-order cost: HANDLES edges (180 here) bind routes to handlers, so Route nodes are otherwise useful. Losing file_path also means Route results can't be correlated with the rest of a result set by path.

Adjacent to the closed #552 (file_pattern returned unfiltered results on 0.8.1) but the opposite direction — this over-filters to zero — and the misleading hint is separate from either.

Reproduction

Repo-independent — any indexed project containing routes:

# confirm Route nodes exist
codebase-memory-mcp cli get_graph_schema --project <slug>
# → node_labels includes {"label":"Route","count":N}

# they return fine unfiltered, and every file_path is ""
codebase-memory-mcp cli search_graph --project <slug> --label Route --limit 5

# add any file_pattern → 0 results + "No nodes with this label"
codebase-memory-mcp cli search_graph --project <slug> --label Route --file-pattern ".*"

--file-pattern ".*" is the clearest form: a pattern that matches everything still returns zero, which isolates the empty file_path as the cause rather than the pattern.

Project scale (if relevant)

TypeScript/Swift/SQL monorepo, 2,250 files, 25,269 nodes / 59,596 edges. 511 Route nodes, 180 HANDLES edges. Reproduced identically through the MCP server and cli mode.

Confirmations

I searched existing issues and this is not a duplicate.
The reproduction is repo-independent — it runs against any indexed project with routes, and the inconsistency is internal to the tool's own get_graph_schema and search_graph output.

The misleading part of this is a real gap in the hint logic, verified: the zero-result hint in handle_search_graph() only branches on name_pattern/label (src/mcp/mcp.c:3564-3577, HEAD 7814e1b):

if (tout.total == 0) {
    if (name_pattern && label) {
        ... "No results. Try removing the label filter or broadening the name_pattern regex."
    } else if (name_pattern) {
        ... "No nodes match this pattern. Check spelling or try a broader regex."
    } else if (label) {
        ... "No nodes with this label. Available labels: ..."
    }
}

file_pattern (and qn_pattern/relationship/min_degree/max_degree) never enter this condition, so any zero-result call that sets label but not name_pattern lands on "No nodes with this label" regardless of which filter actually excluded everything. Confirmed by compiling the branch verbatim in a clean container (gcc:13) with label="Route", file_pattern=".*", name_pattern=NULL, tout.total=0:

inputs: name_pattern=(null) label=Route file_pattern=.* tout.total=0
HINT: No nodes with this label. Available labels: Function, Method, Class, Interface, Route, Variable, Module, Package, File, Folder.

That reproduces the exact wrong hint from a real label with real nodes, so the fix is in the branch condition, not in how Route.file_path gets populated.

On the file_path half: I checked the history of the empty-string creation site you may be tempted to also blame (src/pipeline/pass_route_nodes.c:215, cbm_gbuf_upsert_node(ctx->gb, "Route", url, route_qn, "", ...)). It's deliberate, not an oversight: it dates to 80680ea ("Cross-service communication discovery"), which creates this "infra Route" from a bare HTTP_CALLS/ASYNC_CALLS edge (no local file to attribute it to) and later matches it to a "handler Route" that does carry a real file_path (via match_one_infra_route, same file). So option 1 in the issue (give every Route a real file_path) would break that infra/handler split for repos where the caller is what got indexed. Option 2 (fix the hint) looks like the safe one regardless of why a given project's Route set ends up all-"".

Thank you for separating the missing Route file_path from the misleading zero-result hint. Current filtering applies file_pattern to n.file_path, while the fallback message reports only that the label had no nodes; that combination can produce exactly the false diagnosis you observed. I have removed the unrelated Windows label and routed both the data and UX contracts at high priority in 0.9.1-rc.

Still happening on 0.10.8, and it isn't only Route. Any file_pattern that matches nothing produces the same hint, on a label with thousands of nodes:

--label Function                           -> total: 13006
--label Function --file-pattern '.*src.*'  -> total: 0
  hint: "No nodes with this label. Available labels: Function, Method, Class, ..."

file_path is populated normally here. I'd just used regex syntax where file_pattern wants a glob (filed separately as #2050). The hint still blames the label and then lists it as available in the same sentence.

That lines up with the branch logic quoted above. The hint never looks at file_pattern, so fixing the Route file_path data wouldn't cover this on its own.

fix(mcp): avoid misleading empty-search filter hints

Thank you for the additional 0.10.8 example showing the misleading hint with ordinary populated file paths. That demonstrates why Route attribution alone would not settle the hint problem. I have no new fix to report; no additional examples are requested now.

Thank you for showing the misleading hint also occurs with ordinary file paths. Filter-aware diagnostics remain separate from Route attribution, with enough evidence already supplied. Sorry for the delay; this is waiting on maintainer follow-up, and I’ll follow up soon.

Navigation Menu

Repository navigation

search_graph: Route nodes have empty file_path, so label=Route + file_pattern always returns 0 — and the hint blames the label #1366

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Why this matters

Reproduction

Project scale (if relevant)

Confirmations

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

search_graph: Route nodes have empty file_path, so label=Route + file_pattern always returns 0 — and the hint blames the label #1366

Description

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Why this matters

Reproduction

Project scale (if relevant)

Confirmations

Activity

AmirF194 commented on Jul 31, 2026

DeusData commented on Aug 3, 2026

jaaortega commented on Sep 4, 2026

DeusData commented on Oct 19, 2026

DeusData commented on Oct 25, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions