Skip to content

Cypher: labels() function not recognized, silently drops AS alias and subsequent RETURN items #240

@maksodf

Description

@maksodf

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

  1. labels() function silently returns empty strings (not an error)
  2. AS alias is ignored for the labels() item — column name becomes labels instead of the alias
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions