search_graph name_pattern misses indexed Class nodes found by BM25 query

[thaoula]

Version

codebase-memory-mcp 0.8.1

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

search_graph with name_pattern does not return indexed class nodes that are returned by BM25 query.

Example from a TypeScript/Angular repo:

BM25 query works:

{
  "project": "example-project",
  "query": "ExampleDialogService",
  "label": "",
  "name_pattern": "",
  "limit": 20
}

Returns:
ExampleDialogService
label: Class
file_path: src/app/services/example-dialog.service.ts

But regex name search returns no results:
{
  "project": "example-project",
  "query": "",
  "label": "",
  "name_pattern": ".*ExampleDialogService.*",
  "limit": 20
}
Result:
total: 0

A broader regex also missed expected classes:
"name_pattern": ".*Dialog.*Service.*"

Expected behavior:
- name_pattern should match the indexed Class node by name.
- If name_pattern intentionally searches a different field/scope than BM25, the tool docs or response hint should make that clear.

Impact:
- Agents fall back to grep even though the symbol graph contains the class.
- This makes structural discovery unreliable for class/service inventory tasks.

### Reproduction

- search_graph(query="WorkBuddyDialogService") finds WorkBuddyDialogService as Class
- search_graph(name_pattern=".*WorkBuddyDialogService.*") returns 0
- Same issue with broader .*Dialog.*Service.*

### Logs

```text

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[halindrome]

Reproduced and root-caused — and it's not actually about Class nodes or the regex; the trigger is the empty-string label in the payload.

What's really happening

search_graph's two modes handle an empty label differently:

Call	total
name_pattern=".*CacheService.*" (no label key)	2 ✓
name_pattern=".*CacheService.*", label=""	0 ✗
name_pattern=".*CacheService.*", label="Class"	2 ✓
query="CacheService", label="" (BM25)	28 ✓

The BM25 query path treats an empty label as "absent", but the name_pattern path applies it as a literal n.label = '' filter — which no node satisfies — so it returns 0. Your two example calls differ only in query vs name_pattern, and both carried "label": "", so only the BM25 one worked. The "name_pattern misses Class nodes" behavior is a symptom of that, not a regex/label-scope difference. (Confirmed against a 1,381-class TS/Angular project: with the empty label removed, name_pattern matches all 1,381 classes; with label:"" it returns 0 for every one.)

Root cause

src/store/store.c, search_where_basic:

if (params->label) {                       // guards NULL only, not ""
    snprintf(bind_buf, ... "n.label = ?%d" ...);
    where_append(... "n.label = ?");       // binds n.label = '' → matches nothing
}

An empty-string label is non-NULL, so it's appended as a filter and excludes everything.

Fix

if (params->label && params->label[0]) {   // ignore empty-string label, matching the BM25 path

This makes an empty label a no-op, consistent with an omitted label and with the BM25 query path.

Workaround (today)

Omit the label key entirely (or pass a real label like "Class") rather than "".

Present on current main as well (the search path is unchanged since 0.8.1). I'll open a PR with the fix + a regression test.