Experimental CALL clause and batch api, looking for feedback

[vkozio]

feature/call-subquery-clause
feature/query-batch-api

@adsharma

[adsharma]

There are 67 commits in that feature branch. I can't go through all of them to assess. Could you summarize it for normal humans? :)

[vkozio]

New features in my fork master + help needed (CALL subquery bug)

• Query batch API — Node.js: queryBatchSync / queryBatchAsync (one lock/transaction for N queries).
• CALL (scope) { subquery } is a Cypher reading clause aligned with Neo4j/GQL: it runs an inner subquery with optional scope variables from the outer row and feeds the inner RETURN columns into the outer pipeline, (CallSubquery + ScopeScan).
• Node.js tests for CALL subquery (currently skipped in the runner until the crash below is fixed).
• e2e tests for CALL subquery in test/test_files/call_subquery/.

Everything else (regular queries, batch API, other Node/Cypher features) works. The only known failure is when executing certain CALL subquery queries.

---

Help needed: crash in CALL subquery

Symptom: SIGSEGV (exit 139) when running a query like:

CALL () { RETURN 1 AS x } RETURN x

• Where: Core C++ — crash in Schema::isExpressionInScope (address 0x40 → null or invalid this).
• Same crash from Node API and from e2e; so the bug is in the shared execution path, not in the Node addon.

How to reproduce:

• e2e:
  E2E_TEST_FILES_DIRECTORY=test/test_files build/relwithdebinfo/test/runner/e2e_test --gtest_filter="*call_subquery*CallSubqueryUncorrelated"
  (or run all *call_subquery*).
• Node: run a script that executes CALL () { RETURN 1 AS x } RETURN x (process exits with 139).

What already tried:
Schema for CallSubquery fixed (outer + inner); lazy getSchema() in LogicalOperator; defensive null check in LogicalProjection. Crash still happens → likely use-after-free (dangling Schema*), not just null.

What would help:

1. lldb backtrace at the crash: run the e2e above under lldb, break or continue until SIGSEGV, then bt and inspect who calls isExpressionInScope and where the Schema* comes from (null vs dangling).
2. Narrow the trigger: try correlated CALL subquery (e.g. with scope variables) and see if it crashes the same way or only uncorrelated CALL () { ... }.
3. Ideas on where a Schema might be used after the corresponding plan fragment is destroyed or moved during logical→physical mapping.

If you can run a RelWithDebInfo build and reproduce the crash, a backtrace and any extra findings would be very helpful.

[adsharma]

Thanks. I can help with getting a stack trace.

[adsharma]

Re: this commit

I just landed something in master to fix windows build in CI. What version of MSVC are you using? Why is CI passing without this fix?

commit 3a5e34230eb8de77aa7a257b6ef1c596b107c061
Author: VK <112831093+vkozio@users.noreply.github.com>
Date:   Sun Feb 22 19:09:22 2026 +0300

    fix(windows): replace C compound literals in roaring.c for MSVC C++ build

[adsharma]

lbug> CALL () { RETURN 1 AS x } RETURN x;
Error: Assertion failed in file "/Users/arun/src/ladybug/ladybug-call-clause/src/planner/operator/schema.cpp" on line 21: getGroup(groupPos)->expressionNameToPos.contains(expression->getUniqueName())

lbug> create node table person(id int64, primary key (id));
┌────────────────────────────────┐
│ result                         │
│ STRING                         │
├────────────────────────────────┤
│ Table person has been created. │
└────────────────────────────────┘
(1 tuple)
(1 column)
Time: 11.57ms (compiling), 6.15ms (executing)
lbug> MATCH (a:person) CALL (a) { RETURN 1 AS one } RETURN a.ID, one ORDER BY a.ID;
Error: Assertion failed in file "/Users/arun/src/ladybug/ladybug-call-clause/src/planner/operator/schema.cpp" on line 56: expressionNameToGroupPos.contains(expressionName)

[adsharma]

In other words, running your queries against a debug shell is giving me assertion failures and not SIGSEGV. Let me know if you have a specific query that reproduces.

[adsharma]

Also suggest you frequently rebase against origin/master instead of creating merge commits.

I ran this prompt against an agent:

rebase these changes against origin/master. Some of the commits are already merged.

Results are here: https://github.com/adsharma/ladybug/tree/rebased_call_subquery (19 fewer commits)

Also, please regroup the commits and review the commit messages. Some of the commit messages are stale and do not reflect what's in the code. Suggested grouping:

• windows fixes
• nodejs improvements
• feature branches such as CALL subquery

Instead of carrying 54 commits in a branch, I'd spend time on sending small PRs (preferably one commit at a time) that pass CI.

[adsharma]

Windows CI builds are green again. I suspect the windows PRs you're carrying is because of using a different version of MSVC. Please share your env details so we can sync and get rid of a few commits.

[adsharma]

Based on this overview, I think CALL (scope) { subquery } is a good feature to think about post 0.15.x release:

https://claude.ai/share/a8fb6e21-35f1-4219-8b14-f3123205c8e2

[vkozio]

I'm leaving my works here, have no more time and resources to push it further and fight bugs in core. Hope you find it useful and it will be good base for new cool features.
PRs are stacked.

pr/table-function-multiplicity

pr/query-batch-api

pr/call-subquery-experimental

Thank you for support and good luck.

P.S. I've architected hypergraph DB engine and started implementing it here https://github.com/vkozio/afh so wish me luck:)

[adsharma]

All the best and thank you for the contributions!