Cypher: a query the parser did not fully read returns wrong rows and reports success

[CaptainMittens]

Version

Built from source at ae5de7fe (main), release line v0.10.8

Platform

macOS (Apple Silicon)

Install channel

Built from source

Binary variant

standard

What happened, and what did you expect?

A Cypher query with a tail the parser cannot read returns wrong rows and reports
success. Nothing tells the caller to look.

cbm_parse builds a query and returns success without checking that it read every
token. The grammar accepts at most one WITH and treats RETURN as optional, so the
parser stops at the first thing it does not understand and reports success anyway. The
dropped tail takes the filter and the RETURN with it, and the engine then answers from
the fragment it did parse, using its default projection.

I expected an error naming the token the parser stopped at. A refusal is recoverable; a
plausible wrong answer is not, because nothing downstream can tell it from a real one.

Reproduction

1. Index any project, then run these through query_graph.

2. Trailing garbage is silently dropped:

   MATCH (f:Function) WHERE f.name = 'buildTree' RETURN f.qualified_name AS qn BANANA SPLIT 99
   

   Result: one row, no error. Expected: an error naming BANANA.

3. A second WITH truncates the query, and the filter and RETURN go with it:

   MATCH (f:Function)
   OPTIONAL MATCH (a)-[:CALLS]->(f)
   WITH f, count(a) AS calls
   OPTIONAL MATCH (b)-[:USAGE]->(f)
   WITH f, calls, count(b) AS usages
   WHERE calls = 0 AND usages = 0
   RETURN f.name AS n
   

   Result: rows from the truncated query with the default projection, no error.
   Expected: either full support for the second WITH, or an error saying it is not
   supported.

Logs

No error is emitted — that is the defect.

Diagnostics trajectory (memory / performance / leak issues)

Not applicable — a correctness issue, not memory or performance.

Project scale (if relevant)

Reproduces at any scale.

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.

[adfjadfj16-a11y]

Estimado CaptainMittens, Gracias por enviarnos este reporte tan preciso. Antes de que el equipo comience a trabajar en el parche, ¿podrías indicarnos si has observado este comportamiento en otras versiones del entorno de ejecución o si ocurre únicamente al compilar desde la fuente en Apple Silicon? Esta información nos ayudará a escalar la solución de manera efectiva. Quedamos atentos a tus comentarios. Muchas gracias, Joshua Richter En 31 de agosto de 2026 10:26:30 p. m. GMT-04:00, Joshua Richter ***@***.***> escribió:

…

CaptainMittens created an issue (DeusData/codebase-memory-mcp#1979) ### Version Built from source at `ae5de7fe` (`main`), release line v0.10.8 ### Platform macOS (Apple Silicon) ### Install channel Built from source ### Binary variant standard ### What happened, and what did you expect? A Cypher query with a tail the parser cannot read returns **wrong rows and reports success**. Nothing tells the caller to look. `cbm_parse` builds a query and returns success without checking that it read every token. The grammar accepts at most one `WITH` and treats `RETURN` as optional, so the parser stops at the first thing it does not understand and reports success anyway. The dropped tail takes the filter and the `RETURN` with it, and the engine then answers from the fragment it did parse, using its default projection. I expected an error naming the token the parser stopped at. A refusal is recoverable; a plausible wrong answer is not, because nothing downstream can tell it from a real one. ### Reproduction 1. Index any project, then run these through `query_graph`. 2. Trailing garbage is silently dropped: ``` MATCH (f:Function) WHERE f.name = 'buildTree' RETURN f.qualified_name AS qn BANANA SPLIT 99 ``` Result: one row, no error. Expected: an error naming `BANANA`. 3. A second `WITH` truncates the query, and the filter and `RETURN` go with it: ``` MATCH (f:Function) OPTIONAL MATCH (a)-[:CALLS]->(f) WITH f, count(a) AS calls OPTIONAL MATCH (b)-[:USAGE]->(f) WITH f, calls, count(b) AS usages WHERE calls = 0 AND usages = 0 RETURN f.name AS n ``` Result: rows from the truncated query with the default projection, no error. Expected: either full support for the second `WITH`, or an error saying it is not supported. ### Logs ```text No error is emitted — that is the defect. ``` ### Diagnostics trajectory (memory / performance / leak issues) ```text Not applicable — a correctness issue, not memory or performance. ``` ### Project scale (if relevant) Reproduces at any scale. ### Confirmations - [x] I searched existing issues and this is not a duplicate. - [x] My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code. -- Reply to this email directly or view it on GitHub: #1979 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>