query_graph: property access on a WITH-carried (in-scope) node returns wrong values, not the real property
Version
codebase-memory-mcp 0.10.8 (release binary, b4b403b1d7c4def3785f148b93f345ce8427858f4f5489ce28580c4387a336a6)
Platform
Windows (x64)
Install channel
GitHub release archive / install.sh / install.ps1
Binary variant
standard
What happened, and what did you expect?
When a node variable is carried in scope through a WITH (not dropped — this is distinct from #1919/#1922, which covers a variable the WITH drops), some of its properties resolve to placeholder values instead of the real value when accessed in the following RETURN:
f.qualified_name→ literal string"f"(the variable name itself, not the property value)f.file_path→"-"f.start_line→"0"
f.name is the only property I found that survives correctly. This isn't limited to my own indexed repo — it reproduces on this repository's own graph, see below.
I'd expect every property on an in-scope node to resolve identically whether or not it passed through a WITH, the same guarantee #1922 established for out-of-scope refusal.
Reproduction
- Index this repository itself, or any Python repo.
- Pick any known function, e.g. one with a real caller so the
WITHbranch is actually exercised:MATCH (f:Function {name: 'some_function'}) OPTIONAL MATCH (caller)-[r:CALLS]->(f) WITH f, count(r) AS refs RETURN f.qualified_name, f.file_path, f.start_line, refs - Compare against the same node queried directly, no
WITH:MATCH (f:Function {name: 'some_function'}) RETURN f.qualified_name, f.file_path, f.start_line
Result (query 2, with WITH):
f.qualified_name | f.file_path | f.start_line | refs
f | - | 0 | "264"Result (query 3, no WITH):
f.qualified_name | f.file_path | f.start_line
myproject.db.connect | db.py | 38refs itself is correct (264, matching a heavily-called function) — only the plain property projection on the carried node is corrupted, and silently: no error, no empty-column signal, just wrong data (a literal variable name and numeric/string placeholders) that reads as real output.
Logs
N/A — no crash, exits 0, query_graph reports total: 1 with no warning.
Diagnostics trajectory (memory / performance / leak issues)
N/A — not a memory/performance issue.
Project scale (if relevant)
10,428 nodes / 39,744 edges / 389 Python files (also reproduces on this repo's own ~21k/123k graph via the same query shape).
Confirmations
- I searched existing issues and this is not a duplicate (closest are #1919/#1922, which specifically cover an out-of-scope dropped variable projecting blank columns — this is a different, in-scope-but-still-wrong case).
- My reproduction uses shareable code (a dummy snippet / this repository's own graph), not proprietary code.
Source: DeusData/codebase-memory-mcp