Repository navigation
bug(graph): three query-shape defects — count(*) after OPTIONAL MATCH, phantom collect() map, and C++ toolkit reading m.alias #1533
Description
Three query-shape defects found while cross-checking tool queries against writer.py. All reproduced against a live database.
1. count(*) after OPTIONAL MATCH makes injection_count never zero
tools/handlers/analysis_handlers.py:239-240 and tools/query_tool_languages/java_toolkit.py:109-110
OPTIONAL MATCH ()-[:INJECTS]->(c)
WITH c, count(*) AS injection_countcount(*) counts rows, and an unmatched OPTIONAL MATCH still emits one null row. Against a database with 2 INJECTS edges total, find_java_spring_beans reports injection_count: 1 for Dummy, A, B, C and AbstractThing — none of which anything injects. Switching to count(r) over a bound relationship variable returns 0 correctly.
Effect: "which beans are unused" is unanswerable, and every count is off by one.
2. collect() of a map literal yields a phantom all-null entry
tools/handlers/analysis_handlers.py:299
OPTIONAL MATCH (kp:RedisKeyPattern)-[:STORED_IN]->(d)
RETURN ... collect({pattern: kp.pattern, key_type: kp.key_type, count: kp.count})A map literal is non-null even when every field inside it is null, so collect() does not drop it. find_datasource_nodes returns:
"key_patterns": [{"pattern": null, "key_type": null, "count": null}]for a Redis datasource with no discovered key patterns, instead of []. A consumer doing len(key_patterns) sees 1.
3. C++ toolkit reads m.alias, which no writer ever sets
tools/query_tool_languages/cpp_toolkit.py:46
The query binds the relationship as i but reads the alias off the node:
MATCH (f:File)-[i:IMPORTS]->(m:Module) RETURN ... m.full_import_name, m.aliaswriter.py:580-598 sets r.alias on the relationship; m.alias is never written. Against the live database:
MATCH (m:Module) RETURN count(m), count(m.alias) -> 160, 0
MATCH ()-[i:IMPORTS]->() RETURN count(i), count(i.alias) -> 249, 249
All 249 rows return alias: null while the data sits on the relationship. The elisp and solidity toolkits correctly read i.imported_name / i.full_import_name. (Same root cause as the find_importers issue filed separately — worth fixing together.)
Suggested fix
count(r)over a bound relationship variable instead ofcount(*).- Filter nulls before collecting, or
collect()the node and build maps afterwards. i.aliasinstead ofm.alias.
Environment
| Commit | c0e0bed (main) |
| Backend | Neo4j (live instance) |
| Python | 3.12.3, Linux |
All three reproduced against a live indexed database.
Activity
github-actions commentedon Aug 1, 2026
Hi! 👋 Join our CodeGraphContext Discord channel to collaborate: https://discord.gg/dR4QY32uYQ
Shashankss1205 commentedon Aug 2, 2026
Item 3 is fixed by #1540 (merged) —
cpp_toolkit.py:46now readsi.aliasoff theIMPORTSrelationship instead ofm.aliasoff theModulenode. That PR also fixed the sibling call site infind_importers(#1515) and added a regression test asserting"module.alias" not in query.Still open here:
count(*)afterOPTIONAL MATCH—analysis_handlers.py:239-240andjava_toolkit.py:109-110. An unmatchedOPTIONAL MATCHstill emits one null row, soinjection_countis never 0 and every Spring bean reports at least one injector. Needscount(r)over a bound relationship variable.collect()map —analysis_handlers.py:299. A map literal is non-null even when every field inside is null, sokey_patternscomes back as[{"pattern": null, "key_type": null, "count": null}]instead of[].Both are small and independent — good first issues for anyone looking.
fix(query): five defects that returned wrong answers without erroring (…
Shashankss1205 commentedon Aug 5, 2026
All three items now fixed.
count(*)afterOPTIONAL MATCH) — fixed in fix(query): five defects that returned wrong answers without erroring #1577. Bothanalysis_handlers.pyandjava_toolkit.pynow bind the relationship and usecount(inj), soinjection_countreaches 0 for a bean nothing injects.collect()map) — fixed in fix(query): five defects that returned wrong answers without erroring #1577. The query now collects the node and projects afterwards, so a datasource with no key patterns returns[]instead of[{pattern: null, key_type: null, count: null}].m.alias) — fixed earlier in fix: read import aliases from relationships #1540, which also covered the sibling call site infind_importers(bug(cli/mcp):find_importersreadsmodule.aliasbut the alias is stored on the IMPORTS relationship, soimport_aliasis always null #1515).