fix(cypher): treat unbound variables as unknown in early WHERE

[antespi]

What does this PR do?

WHERE <condition on b> AND NOT <condition on a> returned 0 rows, and the response still reported the empty result as exact (total_relation: eq).

MATCH (a)-[r:CALLS]->(b)
WHERE b.name = 'save' AND NOT (a.file_path CONTAINS 'cancel-order')
RETURN a.name
-- 0 rows, expected 1

NOT on its own, OR NOT and <> all worked. Only NOT as an operand of AND failed, with or without parentheses.

Root cause

• cypher_plan_seed_from_selective_end swaps a single-hop pattern so the scan starts from the end that has an equality on name. In the query above, that is b.
• execute_single then runs an early WHERE on each scanned node. At that point only the seed node is bound, so a is still unbound.
• eval_condition returns true for an unbound variable (if (!actual) return true;). EXPR_NOT flips that to false, so every row is dropped before the pattern is expanded. The late WHERE never gets to see them.
• HAS_LABEL has the same problem: WHERE b.name = 'x' AND a:Function was also pruned to 0, because the label test on an unbound node returns false.

Without the swap (no equality on the far node), the near node is the one bound, which is why NOT alone and OR NOT worked.

Fix

The early WHERE now uses three-valued (Kleene) logic, in eval_expr_tri / eval_where_early:

• A condition whose variable, or any multi-arg function argument, is not bound yet is UNKNOWN.
• AND, OR, NOT and XOR propagate UNKNOWN.
• A row is dropped only when the bound variables already make the WHERE FALSE.

The late WHERE is unchanged and still decides with every variable bound. Pruning stays sound and loses nothing compared with before: a condition on an unbound variable never pruned a row unless something negated it.

eval_expr_tri is recursive like eval_expr, so it is added to CBM_RECURSION_WHITELIST.

Tests

New test cypher_exec_where_and_not_on_unbound_seed_side in tests/test_cypher.c. Each query starts from the far node:

• b = X AND NOT (a.file_path CONTAINS ...)
• b = X AND NOT a.name = ...
• NOT (...) AND b = X (operand order swapped)
• b = X AND NOT (a.p = ... AND a.q CONTAINS ...)
• (b = X AND NOT a.name = ...) OR b = Y (NOT inside AND inside OR)
• b = X AND a:Function (label test on the unbound side)
• negative case: excluding the only caller still returns 0 rows

Results:

• Before the fix, the first assertion fails (0 rows where 1 is expected).
• After the fix, the cypher suite passes (206) and so does mcp (320 passed, 4 skipped).
• lint-no-suppress passes, and the changed files pass clang-format --dry-run --Werror.

I also checked a real index (a NestJS monorepo, about 64k nodes) with WHERE b.name = 'BillableStatusChangedEvent' AND NOT (a.file_path CONTAINS '.spec.'). It returned 0 rows before the fix and returns the one non-spec caller after it.

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects
  unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test): only the cypher and mcp suites were run on this branch
• Lint passes (make -f Makefile.cbm lint-ci): only lint-no-suppress and clang-format on the changed files were run
• New behavior is covered by a test (reproduce-first for bug fixes)

🤖 Generated with Claude Code

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[antespi]

Already fixed in #2253