bug(node binding): MATCH ()-[r]->() RETURN count(r) throws "not found" on 0.1.22 binding

[ryaker]

Summary

The 0.1.22 Node binding regresses on relationship-pattern Cypher queries. Reproducible isolation case below. Node-pattern queries work fine; only relationship-pattern queries fail.

Reproduction (10-line script, fresh node process)

$ cd /Users/ryaker/Dev/KMSmcp  # any KMSmcp checkout with sparrowdb installed
$ node -e "
const sd = require('sparrowdb');
const db = sd.SparrowDB.open('/Users/ryaker/.kms-sparrowdb-v2');
try { console.log('count(n):', db.execute('MATCH (n:Knowledge) RETURN count(n)').rows); } catch (e) { console.log('count(n) ERR:', e.message); }
try { console.log('count(r):', db.execute('MATCH ()-[r]->() RETURN count(r) AS cnt').rows); } catch (e) { console.log('count(r) ERR:', e.message); }
try { console.log('count(r2):', db.execute('MATCH ()-[r]-() RETURN count(r) AS cnt').rows); } catch (e) { console.log('count(r2) ERR:', e.message); }
"

Output:

count(n): [ { 'count(n)': 1013 } ]
count(r) ERR: not found
count(r2) ERR: not found

Error code on the thrown Error object: GenericFailure.

Environment

• KMSmcp consumer machine (Mac mini, darwin-arm64)
• node_modules/sparrowdb/package.json declares version: 0.1.20, but the actual .node binary is from the 0.1.22 work landed in feat(node): wire hybridSearch + bump 0.1.21 → 0.1.22 #404/build(node): regenerate TS surface with @napi-rs/cli; expose vector/FTS/hybrid types #405 (propagated via KMSmcp PR fix(storage): zero-pad missing columns on create_node to prevent slot misalignment (SPA-187) #57's build:sparrowdb script).
• DB at /Users/ryaker/.kms-sparrowdb-v2 was previously serviced by the prior 0.1.21 binding without issue (1013 Knowledge nodes, ~700 relationships).
• Direct prototype introspection confirms all 7 new methods (hybridSearch, vectorSearch, vectorSimilarity, fulltextSearch, createVectorIndex, createFulltextIndex, execute) are present.

Impact on KMSmcp

Surfaces in SparrowDBStorage.getStats() and any _getRelationships traversal — KMSmcp's unified_search lost RELATED_TO/ABOUT edge enumeration after the 0.1.22 cutover. KMS service was reporting status: degraded until I added a try/catch workaround in PR #59 that defaults rel count to 0 when the query throws.

Workaround in KMSmcp is a band-aid — the real fix is here. Once shipped, KMSmcp will revert the workaround and use the rel count again.

Suspected scope

• Whether OPTIONAL MATCH on rels works either
• Whether MATCH (a)-[r]->(b) WHERE ... RETURN r (i.e., bound endpoints) works
• Whether the regression is execution-engine or Cypher-parsing

If you want me to run additional Cypher probes against the live DB to narrow the scope, let me know — happy to script an isolation pass.

Related

• Closed: feat(vector): HNSW vector index + cosine/dot/euclidean similarity search #394, feat(fts): BM25 full-text index + CONTAINS/STARTS WITH acceleration #395, feat(hybrid-search): RRF fusion of vector + BM25 results in single Cypher query #396, feat(node): expose vector index + FTS + hybrid search via NAPI bindings (#400) #401 (vector/FTS/hybrid landing)
• KMSmcp PR fix(engine): resolve $param in UNWIND from query parameters map — SPA-190 #59 (workaround so KMS service doesn't degrade)