Crash when calling query_graph

[zbynekwinkler]

Version

codebase-memory-mcp 0.8.1

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

After indexing I tasked my agent to find dead code. It started calling the mcp and it has crashed almost on the first useful query.

Reproduction

It is a private codebase. I had to check the box that it is not. I am doing so in the hopes that it might help anyway.

codebase-memory-mcp cli query_graph '{"project": "YYY", "query": "MATCH (f:Function) WHERE NOT f.file_path CONTAINS ''ext'' AND NOT f.file_path CONTAINS ''Tests'' AND NOT f.file_path CONTAINS ''examples'' AND NOT f.name = ''main'' OPTIONAL MATCH (c)-[:CALLS]->(f) WITH f, c WHERE c IS NULL RETURN f.name, f.qualified_name, f.file_path, f.start_line ORDER BY f.file_path LIMIT 50"}'

no usefull output, just a crash dump appearing in AppData\Local\CrashDumps\

Logs

PS C:\Users\XXX\AppData> codebase-memory-mcp cli query_graph '{"project": "YYY", "query": "MATCH (f:Function) WHERE NOT f.file_path CONTAINS ''ext'' AND NOT f.file_path CONTAINS ''Tests'' AND NOT f.file_path CONTAINS ''examples'' AND NOT f.name = ''main'' OPTIONAL MATCH (c)-[:CALLS]->(f) WITH f, c WHERE c IS NULL RETURN f.name, f.qualified_name, f.file_path, f.start_line ORDER BY f.file_path LIMIT 50"}'
level=info msg=mem.init budget_mb=32596 total_ram_mb=65192
PS C:\Users\XXX\AppData>

Project scale (if relevant)

Nodes: 29,361 Edges: 59,940

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[zbynekwinkler]

I think I have it crashing also under wsl.

[zbynekwinkler]

That is actually a local build of current main.

[zbynekwinkler]

I asked the agent to try to minimize the crashing query:

[zbynekwinkler]

btw: It is a really slow to rebuild. Iterating on a fix is not as fast as it could be.

[zbynekwinkler]

I had my agent take a look and it was able to generate some kind of a fix (let me know if you are interested in it). I had the original agent testing it on the private repo and after a couple of iterations, they fixed it. This is the final report:

Details

Here is the complete, comprehensive list of **all four bugs/limitations** we identified and diagnosed in the graph engine during this session:

1. 🔴 Bare Variable-Binding Corruption (Fixed)

• What it was: Projecting a node/relationship variable through a WITH clause (e.g., WITH f or WITH f AS func) stripped its property map and bound the variable to a literal string equal to its own identifier name (e.g., "f" or "func"). Any subsequent property lookup (f.qualified_name) evaluated to that string.
• Status: 🟢 Resolved (Verified fixed in the first patch).

2. 🔴 Traversal Outer-Join Process Crash (Fixed)

• What it was: Performing an OPTIONAL MATCH (outer-join/null-padding traversal) over large node/relationship collections crashed the server binary with Connection closed. This was isolated as a crash in the optional matching planner/traversal executor itself, separate from any WITH or WHERE operations.
• Status: 🟢 Resolved (Verified fixed in the latest patch).

3. ⚠️ Cypher Parser Nesting Limitations (Constraint)

• What it is: The Cypher parser throws syntax errors on standard openCypher nested pattern checks inside WHERE clauses (e.g., WHERE NOT (f)<-[:CALLS]-() throws an unexpected operator error).
• Workaround: Avoid nested pattern checks in WHERE; use explicit MATCH structures or property filtering instead.

4. ⚠️ Inline Projections Logic Errors (Constraint)

• What it is: The parser throws parser token errors when evaluating boolean expressions or literal values directly inside WITH projections (e.g., WITH (r IS NULL) AS is_uncalled throws expected token type 85, got 66 or WITH 1 AS x throws expected token type 0, got 13).
• Workaround: Project node properties directly (e.g., WITH f.qualified_name AS qname, caller.name AS caller_name) which evaluates correctly, and run subsequent operations on those primitives.

I also have several handoff documents from the session.

I see that you most likely have a fairly good idea what is going on given the recent 2534f3b, so let me know if you want any more of this.

[DeusData]

Hey @zbynekwinkler, yes currently looping through all the issues and trying to find ways to reproduce all the issues and fix them once and for all. Also having some other people on it. Still, would be interested if you could share your reports :) Always helpful to get more information

[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.)

[zbynekwinkler]

The commits my agent produced are a99a419 and 3fd3543. I'll try to dig up the handoff as well later (they are on a different computer).

[zbynekwinkler]

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

I see

• QA: reproduce-first bug suite + LSP/grammar extraction fixes (5-platform board green) #667

got merged. I'll try to verify the fix.