query_graph: property access on a WITH-carried (in-scope) node returns wrong values, not the real property

[bhaveshpatelapple]

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

1. Index this repository itself, or any Python repo.
2. Pick any known function, e.g. one with a real caller so the WITH branch 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
   

3. 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.