trace_path returns empty for all functions despite traversable CALLS edges (v0.8.1, macOS arm64)

[mattiagggg]

Summary

trace_path returns an empty result for every function/method I tried — callers or callees, plain or fully-qualified name, any depth — even though the underlying CALLS edges exist and are traversable via query_graph. The tool only ever echoes back {"function":...,"direction":...} with no paths/nodes.

This makes the headline call-graph traversal tool effectively non-functional in v0.8.1, at least on macOS arm64.

Environment

• Version: codebase-memory-mcp 0.8.1
• Platform: Darwin arm64 (macOS)
• Repo indexed: large polyglot repo (Python 569 files, Go 190, TS 20, …) → 15,915 nodes / 67,668 edges, status:"indexed". Index reports 15,945 CALLS edges.

Repro

Index any multi-language repo, then:

$ codebase-memory-mcp cli trace_path '{"project":"<proj>","function_name":"read_file_status","direction":"callers","depth":1}'
{"function":"read_file_status","direction":"callers"}

Empty — no paths. But the edges clearly exist:

$ codebase-memory-mcp cli query_graph '{"project":"<proj>","query":"MATCH (a)-[:CALLS]->(b:Function) RETURN b.name, count(a) AS callers ORDER BY callers DESC LIMIT 8"}'
{"columns":["b.name","callers"],"rows":[["get",380],["info",374],["main",169],["load",112],["read_file_status",88],["save_files_from_dict",87],["WithTimeout",72],["keys",63]]}

read_file_status is a Function node with 88 incoming CALLS edges, yet trace_path finds nothing.

What I ruled out

• Not a label issue. Tried both Method nodes (create) and Function nodes (read_file_status, save_files_from_dict, main, run_cmd) — all empty.
• Not direction. callers and callees both empty.
• Not name resolution. Bare name and fully-qualified (agentsv2.base_agent.BaseAgent.create) both empty.
• Not missing data. The exact CALLS edges traverse fine via query_graph, so the graph is populated correctly — only the trace_path start-node lookup (or its traversal) appears to fail.

Expected

trace_path should return the caller/callee paths for read_file_status (88 callers exist), matching what query_graph can already walk.

Workaround

Use query_graph with a Cypher MATCH ... -[:CALLS*]-> ... instead; the graph data itself is correct.

[halindrome]

Confirming this is a real bug — reproduced independently on a separate repo and on a build from current main (not just v0.8.1), also macOS arm64.

A Perl project indexed with the same tree shows three refreshProperties definitions each with inbound CALLS edges via query_graph:

query_graph  MATCH (a)-[:CALLS]->(b:Function) WHERE b.name='refreshProperties' ...
→ Corvex.Assets.refreshProperties    8 callers
  Corvex.Objects.refreshProperties   6 callers
  Corvex.Questions.refreshProperties 5 callers

…but trace_path returns empty for the same functions, with both the bare and fully-qualified name:

trace_path {"function_name":"refreshProperties","direction":"callers","depth":1}
→ {"function":"refreshProperties","direction":"callers"}

trace_path {"function_name":"<proj>.apps.rest-api.lib.Corvex.Assets.refreshProperties","direction":"callers","depth":1}
→ {"function":"<proj>...refreshProperties","direction":"callers"}

So the response carries no paths/nodes key at all — matching the report. The graph data is correct and walkable via Cypher (MATCH ... -[:CALLS]-> ...), so this is isolated to trace_path's own start-node lookup/traversal, not edge creation or name resolution. The query_graph Cypher workaround in the issue holds up.

[DeusData]

Thanks for the careful report, @mattiagggg 🙏 The split you found is the key clue: the edges traverse fine via query_graph, but trace_path returns nothing, so the graph data is correct and this is a start node lookup or traversal bug inside trace_path itself, not extraction. The fact that bare and fully qualified names both come back empty points at the name to node resolution step.

This may be related to the name resolution work in #466, and we're checking whether that path covers trace_path's lookup too. One thing that would help narrow it: does trace_path return anything for a symbol whose name is globally unique in your repo (no overloads or duplicates)? If unique names work but ambiguous ones don't, it's the resolver; if even unique names fail, it's the traversal. This is a core tool, so it's high on our list!

[DeusData]

This issue now has a first-class, durable reproduction in the cumulative bug-reproduction suite landing in #667 — a test that pins the exact failing behaviour, so it's tracked and guarded against silent regression. Where #667 also lands the root-cause fix, that's called out in the PR; otherwise the reproduction makes the eventual fix straightforward and verifiable.

The reproduction goes live once #667 merges. (Posted from the release branch's QA pass.)

[doug306]

Corroborating on a different platform, with one extra data point that may help narrow it.

Platform: macOS x86_64 (Intel), v0.8.1 release binary — so this isn't arm64-specific.

Key clue: trace_path with mode:"data_flow" works, while the default mode:"calls" returns empty, on the same function and index.

Minimal repro (2-file TS project where greet() calls helper(), and run() calls greet()):

# The CALLS edges exist:
cli query_graph '{"project":"P","query":"MATCH (a)-[:CALLS]->(b) RETURN a.name,b.name"}'
# → rows: [["greet","helper"],["run","greet"]]

# mode=calls — empty:
cli trace_path '{"project":"P","function_name":"helper","direction":"callers","mode":"calls","depth":2}'
# → {"function":"helper","direction":"callers","mode":"calls"}

# mode=data_flow — correct, with hops:
cli trace_path '{"project":"P","function_name":"greet","mode":"data_flow","depth":3}'
# → {... "callees":[{"name":"helper","hop":1}], "callers":[{"name":"run","hop":1}]}

Same on a large real repo: mode:"calls" is empty for an exported function with 41 inbound CALLS edges (confirmed via query_graph), but mode:"data_flow" returns 89 transitive caller entries at depth 2. Identical behavior via cli and via MCP tools/call.

Since data_flow resolves the same bare name and traverses the same nodes/edges successfully, the name→node lookup and the edges themselves look fine — the empty result seems specific to the calls-mode traversal/serialization path, rather than name resolution.