trace_path returns empty for nodes that have CALLS edges (v0.9.0, repro included)

[junk151516]

Environment: v0.9.0, Windows amd64 (ui variant), repo indexed with --mode moderate. Mixed Python (FastAPI) + Svelte/TS monorepo, ~31k nodes / 176k edges, 43,851 CALLS edges.

Summary: trace_path returns an empty trace for every node I tested — plain Function nodes and Method nodes alike — even when query_graph confirms incoming/outgoing CALLS edges for the exact same node. Name disambiguation works (ambiguous names return correct suggestions), but the traversal itself yields nothing.

Repro 1 — Function node, edge confirmed

# The edge exists (seen in a raw edge sample: caller "App" → callee "fmt"):
cli query_graph --project P --query "MATCH (a)-[r:CALLS]->(b) WHERE b.name = 'fmt' RETURN a.name"
# → rows: [["App"]]

# Ambiguous short name → correct suggestions (so node resolution works):
cli trace_path --project P --function-name fmt --direction callers --depth 1
# → {"status":"ambiguous", suggestions: [<qualified_name_1>, <qualified_name_2>]}

# Passing the EXACT qualified_name the tool itself suggested:
cli trace_path --project P --function-name '<qualified_name_1>' --direction callers --depth 1
# → {"function":"<qualified_name_1>","direction":"callers"}   ← empty, no paths, no error

Repro 2 — Method node (Python service class)

# Two incoming CALLS edges confirmed via Cypher:
cli query_graph --project P --query "MATCH (a)-[r:CALLS]->(b) WHERE b.name = 'auto_match' RETURN a.qualified_name"
# → 2 rows (a FastAPI route handler + a background worker handler) — both correct vs. grep

cli trace_path --project P --function-name auto_match --direction callers --depth 3
# → {"function":"auto_match","direction":"callers"}           ← empty

cli trace_path --project P --function-name '<full qualified_name of the Method>' --direction callers --depth 3
# → empty as well. Same for --direction callees.

Expected: the same callers/callees that query_graph returns over CALLS edges.

Impact: impact-analysis via trace_path is unusable on this index; query_graph with a WHERE clause is the workaround. Happy to run any diagnostic build or share index stats (the codebase itself is private).

[DeusData]

Thanks for the detailed v0.9.0 reproduction. This is a 100% match for the canonical trace_path calls-mode failure in #480: CALLS edges are present and traversable through query_graph, while trace_path returns an empty result for bare and fully qualified Function/Method names in both directions. I have copied the current-version evidence to #480 and returned it to the maintainer queue. Closing this report as a duplicate of #480 so diagnosis and the RED regression stay in one place.

[frankliu7]

Still reproducible on v0.9.0, macOS arm64, --mode full — this issue was closed on 2026-07-16, but the original repro (Windows amd64, --mode moderate) reproduces on a different platform and index mode. Requesting reopen.

Environment

• v0.9.0, darwin/arm64 (standard, non-UI variant), installed via install.sh
• Private Python monorepo, indexed with --mode full
• Graph: 81,527 nodes / 301,976 edges, 61,579 CALLS edges
• Tested via cli (no MCP client involved), single project in cache at the time

Symptom: identical to Repro 1 above — trace_path returns an empty object for every node tested, while query_graph confirms the incoming CALLS edges for the same node. Node resolution works (ambiguous short names return correct suggestions); the traversal yields nothing. No error, no empty-result marker.

Repro

# 1. Node resolution works — search_graph finds exactly one match
$ cbm cli search_graph --project P --query "<fn>" --limit 3
{"total":1,"search_mode":"bm25","results":[{"name":"<fn>",
 "qualified_name":"P.<pkg>.<mod>.<fn>","label":"Function",
 "file_path":"<pkg>/<mod>.py","start_line":461,"end_line":568,...}]}

# 2. query_graph confirms incoming CALLS edges for that exact node
$ cbm cli query_graph --project P \
    --query "MATCH (a)-[:CALLS]->(b) WHERE b.name = '<fn>' RETURN a.name, a.file_path LIMIT 10"
{"columns":["a.name","a.file_path"],"rows":[
 ["<caller1>","<pkgA>/<modA>.py"],
 ["<caller2>","<pkgB>/<modB>.py"],
 ... ],"total":10}

# 3. trace_path with the exact qualified_name from step 1 → empty
$ cbm cli trace_path --project P \
    --function-name "P.<pkg>.<mod>.<fn>" --direction callers --depth 2
{"function":"P.<pkg>.<mod>.<fn>","direction":"callers"}      # ← empty, no error

Ground truth for <fn>: 124 references across the repo (grep -rn), of which the Cypher query above surfaces real callers correctly.

Also reproduced with:

• plain (unqualified) function name → same empty object
• --direction callees → same empty object
• a second, differently-shaped function (module-level, conventionally called, non-aliased import) → same empty object

So on this repo trace_path returned empty for 4/4 functions tested, across both directions, while the underlying CALLS edges were present and traversable via query_graph.

Why this matters beyond the tool being wrong: the failure is silent. An agent calling trace_path receives a well-formed response with no results and no error, which reads as "this function has no callers" — a confidently wrong answer rather than a visible failure. query_graph is a working substitute, but only if the caller already knows trace_path cannot be trusted.

Possibly the same root cause as #763 (CALLS edges falling back to File/Module nodes when enclosing_func_qn is unset); filing here since this is the v0.9.0-specific report and it is currently closed.

[junk151516]

Original reporter here. Before this gets reopened as a traversal bug — prompted by @frankliu7's comment I went back to my index (same v0.9.0 binary, Windows amd64) and found the actual root cause of the empty responses, at least on my side. I believe it applies to the comment above too.

--direction callers — which my original repro used, and which the repro above reuses — is not a valid value. The accepted values are inbound / outbound / both. Anything else is accepted silently and echoed back in a well-formed, empty response:

cli trace_path --project P --function-name '<qn>' --direction callers
# → {"function":"<qn>","direction":"callers"}      ← empty, no error
cli trace_path --project P --function-name '<qn>' --direction patito
# → {"function":"<qn>","direction":"patito"}       ← any garbage value "works"
cli trace_path --project P --function-name '<qn>' --direction inbound
# → full caller tree — correct for both Function and Method nodes,
#   verified against Cypher over CALLS edges and against grep

So on my repo trace_path works fine once the direction is valid — including the exact Method node from Repro 2 of this issue. @frankliu7: could you retest with --direction inbound? Your steps use callers as well, which would also explain why this "reproduces" across platforms and index modes — it isn't platform-dependent at all.

If that's confirmed, the actionable bug here is: invalid direction values should be rejected with an explicit error, not swallowed into a response indistinguishable from "this function has no callers". That's exactly the failure family of #1111 / #1133, already slated for the fail-explicit treatment in 0.9.1-rc — this enum belongs in that batch. The "silent confidently-wrong answer to an LLM agent" concern raised above is real; it's just one validation away from fixed.

---

One more silent-empty found while investigating (happy to file it as its own issue): on the same v0.9.0 binary and DB, query_graph patterns with no label on the source node now silently return 0 rows whenever they carry a WHERE or a typed relationship, while the label-anchored equivalent returns correct rows:

MATCH (a)-[r:CALLS]->(b) WHERE b.name = 'X' RETURN a.qualified_name   → 0 rows (silent)
MATCH (a:Function)-[r:CALLS]->(b) WHERE b.name = 'X' RETURN ...       → correct callers
MATCH (a)-[r:CALLS]->(b:Method) WHERE b.name = 'X' RETURN ...         → 0 rows (label on the TARGET doesn't help)
MATCH (n) WHERE n.name = '<existing>' RETURN ...                      → 0 rows; ✅ with (n:Method)

Notably, the unlabeled form returned 2 correct rows on 2026-07-15 (quoted verbatim in this issue's body). The binary didn't change (SHA-pinned); the DB has since been through several delete_project + fresh-index cycles and incremental auto-watch updates — so it smells like stale per-label state consulted by unlabeled matching, while label-anchored plans still read live data. Reproduced on two projects in the same DB, with string and numeric predicates, via both the CLI and the MCP server.

[DeusData]

Thanks to both of you for retesting and isolating this. The evidence shows that this should not be reopened as a traversal failure: inbound works, while callers and other invalid values are silently accepted. I have corrected the canonical #480 title and acceptance criteria to track explicit direction validation. The separate unlabeled query_graph regression is already isolated in #1196, so this issue can remain closed as a duplicate.