Environment
- cbm version: 0.6.0
- Platform: macOS (Darwin arm64)
Bug
The standard Cypher labels(n) function is not recognized, and the failure mode is silent data corruption: it causes the column AS alias to be dropped and subsequent RETURN items to be silently truncated from the result. Two separate symptoms from one root cause.
Minimal reproducer
MATCH (n) WHERE n.file_path CONTAINS 'JarvisApp.swift'
RETURN n.name AS name, labels(n) AS lbl, n.label AS lbl_prop
LIMIT 5
Expected: three columns name, lbl, lbl_prop, with lbl being a list of label strings like ["Class"].
Actual: two columns name, labels — the AS lbl alias is ignored (column is named labels after the function), lbl values come back as empty strings, and the entire third RETURN item (n.label AS lbl_prop) is silently dropped from the result even though it's unrelated to labels().
Sample response:
{"columns":["name","labels"],"rows":[["AppDelegate",""],["JarvisApp",""], ...],"total":14}
Symptoms summary
labels() function silently returns empty strings (not an error)
AS alias is ignored for the labels() item — column name becomes labels instead of the alias
- Any subsequent
RETURN items after a labels() item are dropped entirely from the result
Root cause (hypothesized)
There is no TOK_LABELS in the cbm_token_type_t enum in src/cypher/cypher.h. labels is being tokenized as a regular identifier. The parser then fails on labels(n) at some point in parse_return_item (line 1138) and either returns an error silently or corrupts the return_clause->items array truncating everything after the failing item.
Proposed fix
Add TOK_LABELS to the enum, add "labels" to keyword_lookup, handle it in parse_return_item as a node-accessor function (similar to how toLower/toUpper/toString are handled), and implement the executor to return a list of the node's labels from node->label or the underlying store. Medium fix.
Alternatively, at minimum: make the parser fail loudly on unknown functions instead of silently dropping items. That prevents the silent-data-corruption failure mode regardless of whether labels() is supported.
Happy to open a PR if useful.
Environment
Bug
The standard Cypher
labels(n)function is not recognized, and the failure mode is silent data corruption: it causes the columnASalias to be dropped and subsequent RETURN items to be silently truncated from the result. Two separate symptoms from one root cause.Minimal reproducer
Expected: three columns
name,lbl,lbl_prop, withlblbeing a list of label strings like["Class"].Actual: two columns
name,labels— theAS lblalias is ignored (column is namedlabelsafter the function),lblvalues come back as empty strings, and the entire third RETURN item (n.label AS lbl_prop) is silently dropped from the result even though it's unrelated tolabels().Sample response:
{"columns":["name","labels"],"rows":[["AppDelegate",""],["JarvisApp",""], ...],"total":14}Symptoms summary
labels()function silently returns empty strings (not an error)AS aliasis ignored for thelabels()item — column name becomeslabelsinstead of the aliasRETURNitems after alabels()item are dropped entirely from the resultRoot cause (hypothesized)
There is no
TOK_LABELSin thecbm_token_type_tenum insrc/cypher/cypher.h.labelsis being tokenized as a regular identifier. The parser then fails onlabels(n)at some point inparse_return_item(line 1138) and either returns an error silently or corrupts thereturn_clause->itemsarray truncating everything after the failing item.Proposed fix
Add
TOK_LABELSto the enum, add"labels"tokeyword_lookup, handle it inparse_return_itemas a node-accessor function (similar to howtoLower/toUpper/toStringare handled), and implement the executor to return a list of the node's labels fromnode->labelor the underlying store. Medium fix.Alternatively, at minimum: make the parser fail loudly on unknown functions instead of silently dropping items. That prevents the silent-data-corruption failure mode regardless of whether
labels()is supported.Happy to open a PR if useful.