Repository navigation
Description
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 | 38
refs 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 query_graph: a variable the WITH clause dropped is still accepted, and its column comes back empty with no error #1919/fix(cypher): refuse a name that is not in scope instead of projecting a blank column #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.
Activity
DeusData commentedon Sep 25, 2026
Thank you @bhaveshpatelapple for such a precise report. Comparing the same node with and without the WITH, and separating it clearly from #1919/#1922, made this quick to pin down. You were right that it's silent wrong data, which is the worst kind.
The cause: when a node passed through WITH, the engine didn't carry the node itself. It carried a small placeholder holding only the node's name, and it used the placeholder's
qualified_nameslot to store the variable name. That's whyf.qualified_namecame back as "f" andf.start_lineas "0", whilef.namelooked fine. The same path groupedWITH f, count(...)by function name, so different functions with the same name were silently merged into one row.The fix (#2351) carries the real node through WITH, so every property resolves exactly as it does without the WITH. It also groups by node identity, stops scalar WITH aliases from exposing their own name as
qualified_name, and makesWITH f AS g ORDER BY g.<prop>sort on the real value. Regression tests cover your exact query shape.While checking this, we noticed that
count(r)over an OPTIONAL MATCH with no match counts 1 instead of 0. That's a separate bug and we'll track it on its own. Thanks again!Merge pull request #2351 from DeusData/fix/issue-2208
fix(cypher): carry the real node through WITH, not a name-only stub (D…
DeusData commentedon Sep 30, 2026
Thank you again for reporting this, @bhaveshpatelapple! The fix is now on
mainin 372aff2 (merged via #2351), and it will ship in the next release.