feat(merk,grovedb): add no-proof query_aggregate_count entry point

[QuantumExplorer]

Issue being fixed or feature implemented

Adds a no-proof execution variant of AggregateCountOnRange. Callers that need a count value but not a proof (e.g. server handlers answering prove=false count requests) previously had to call prove_query and discard the proof bytes. That wastes CPU and allocations on proof construction / serialization for a count that's then thrown away, and reads as confused intent.

Caller context: dashpay/platform#3623 wires up the unified GetDocumentsCount endpoint with range-count support over range_countable indexes; its summed-mode path walks every emitted element in Rust today (O(distinct values in range)). With this primitive available, that path becomes O(log n) and drops directly into execute_range_count_no_proof.

What was done?

• merk: Merk::count_aggregate_on_range walks the same Contained / Disjoint / Boundary classification as prove_aggregate_count_on_range, using each internal node's stored aggregate count to short-circuit fully-inside / fully-outside subtrees, but emits no proof ops. NonCounted-correctness is preserved via the same own_count = node_count − left_struct − right_struct derivation the prover uses (NonCounted leaves have stored aggregate 0 → own_count 0). Tree-type gate (ProvableCountTree / ProvableCountSumTree only) and empty-merk-returns-0 contract are identical to the proof variant.
• grovedb: GroveDb::query_aggregate_count(path_query, transaction, grove_version) -> CostResult<u64, Error>. Validates the PathQuery shape up front via validate_aggregate_count_on_range (same gate the prover and verifier use), opens the leaf merk at path_query.path, and delegates to the merk-level walk.
• version: new query_aggregate_count_on_range field on GroveDBOperationsQueryVersions, wired through v1/v2/v3 at version 0.

The returned count is not independently verifiable — callers trust their own merk read path. For a verifiable count, callers continue to use prove_query + verify_aggregate_count_query. The doc comments on both entry points say so explicitly.

How Has This Been Tested?

Merk-level (6 new tests, merk/src/proofs/query/aggregate_count.rs):

• no_proof_matches_prover_closed_range_inclusive
• no_proof_matches_prover_closed_range_exclusive
• no_proof_matches_prover_open_range_from
• no_proof_matches_prover_range_below_all_keys
• no_proof_empty_merk_returns_zero
• no_proof_rejected_on_normal_tree

Each cross-checks count_aggregate_on_range against the prover's count for the same merk + range, so any divergence between the two walks fails the test.

GroveDB-level (11 new tests, grovedb/src/tests/aggregate_count_query_tests.rs):

• All range variants (inclusive, exclusive, from, after, to-inclusive, disjoint)
• ProvableCountTree and ProvableCountSumTree
• 3-layer path (single- and multi-layer parents)
• Empty ProvableCountTree returns 0
• Invalid inner range (Key) rejected with Error::InvalidQuery before storage reads
• NormalTree rejected via Error::MerkError from the merk-level gate

Each test cross-checks the no-proof result against the proof variant (prove_query + verify_aggregate_count_query).

Suite: full merk lib (cargo test -p grovedb-merk --lib) → 415 passing; full grovedb lib (cargo test -p grovedb --lib) → 1507 passing, 0 failed.

Breaking Changes

None. The new field on GroveDBOperationsQueryVersions is additive and starts at 0 across all versions. No existing API signatures changed.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Added aggregate count query functionality that returns item counts for range queries without generating cryptographic proofs, offering improved performance for count-only operations.
  • Extended version tracking system to support the new aggregate count query capability.

[coderabbitai]

Warning

Rate limit exceeded

@QuantumExplorer has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 47 minutes and 55 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 84100af6-c0fe-4291-98b5-06c7713c502c

📥 Commits

Reviewing files that changed from the base of the PR and between 4f2820e and 93ec94e.

📒 Files selected for processing (3)

• grovedb/src/tests/aggregate_count_query_tests.rs
• merk/src/merk/get.rs
• merk/src/proofs/query/aggregate_count.rs

📝 Walkthrough

Walkthrough

This PR adds a no-proof variant of aggregate count on range queries to GroveDB. It extends version management, implements counting traversal in the merk layer, exposes a public query_aggregate_count API in GroveDB, and provides comprehensive test coverage validating consistency with proof-based results.

Changes

No-Proof Aggregate Count Query

Layer / File(s)	Summary
Version Contract grovedb-version/src/version/grovedb_versions.rs, grovedb-version/src/version/v1.rs, grovedb-version/src/version/v2.rs, grovedb-version/src/version/v3.rs	Adds query_aggregate_count_on_range: FeatureVersion field to GroveDBOperationsQueryVersions struct; initializes the field to 0 in GROVE_V1, GROVE_V2, and GROVE_V3 version constants.
Merk Counting Implementation merk/src/merk/prove.rs, merk/src/proofs/query/aggregate_count.rs	Implements RefWalker::count_aggregate_on_range with helper functions provable_count_from_walker and walk_count_only to traverse the tree and compute in-range counts without emitting proofs; delegates from Merk::count_aggregate_on_range to RefWalker; validates tree type and returns 0 for empty merks.
GroveDB Public API grovedb/src/operations/get/query.rs	Adds GroveDb::query_aggregate_count method that validates query shape, opens the target merk subtree transactionally, calls merk-level counting, and returns the u64 result with cost accounting.
Test Coverage grovedb/src/tests/aggregate_count_query_tests.rs, merk/src/proofs/query/aggregate_count.rs	Introduces helper no_proof_matches_proof for cross-checking no-proof results against prove→verify; adds success-path tests for ProvableCountTree and ProvableCountSumTree variants; covers failure cases: invalid range shapes, wrong tree types, missing paths, and empty trees; extends merk-level tests to validate count consistency across range shapes.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 A count without proof, swift and light,
Through aggregate ranges, climbing the height,
No proofs to verify, just numbers so true,
Merk walks the tree, old and new!
GroveDB now counts with a whisper, not shout.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title accurately reflects the main change: adding a no-proof query_aggregate_count entry point across merk and grovedb. It is concise, specific, and clearly summarizes the primary objective.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/determined-edison-b2dd07

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

❌ Patch coverage is 94.20849% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.76%. Comparing base (dbd83dc) to head (93ec94e).
⚠️ Report is 1 commits behind head on develop.

Files with missing lines	Patch %	Lines
merk/src/proofs/query/aggregate_count.rs	95.65%	9 Missing ⚠️
grovedb/src/operations/get/query.rs	80.00%	6 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #662      +/-   ##
===========================================
+ Coverage    90.74%   90.76%   +0.01%     
===========================================
  Files          184      184              
  Lines        55532    55791     +259     
===========================================
+ Hits         50395    50639     +244     
- Misses        5137     5152      +15     

Components	Coverage Δ
grovedb-core	88.52% <80.00%> (-0.02%)	⬇️
merk	92.32% <96.06%> (+0.05%)	⬆️
storage	86.36% <ø> (ø)
commitment-tree	96.43% <ø> (ø)
mmr	96.76% <ø> (ø)
bulk-append-tree	89.14% <ø> (ø)
element	95.75% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

grovedb/src/tests/aggregate_count_query_tests.rs (1)

1443-1459: ⚡ Quick win

Make the transaction test observe uncommitted state.

Starting the transaction after all data is already committed only proves that Some(&tx) doesn't error. This still passes if query_aggregate_count ignores the transaction and reads from the base view. A small uncommitted insert/delete inside tx, plus a None vs Some(&tx) assertion, would turn this into a real regression test for transaction threading.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@grovedb/src/tests/aggregate_count_query_tests.rs` around lines 1443 - 1459,
The test no_proof_uses_provided_transaction currently starts the transaction
after all data is committed, so change it to make the transaction observe
uncommitted state: after calling let tx = db.start_transaction() perform a
mutating operation inside that transaction (e.g., insert or remove a key under
the same path used by PathQuery via the transaction API) that will change the
expected aggregate count by ±1, then call
grove_db.query_aggregate_count(&path_query, Some(&tx), v) and assert the
returned count reflects the uncommitted change, and also call
grove_db.query_aggregate_count(&path_query, None, v) (or before the tx mutation)
to assert the base view does not include the change; use the existing symbols
tx, query_aggregate_count, PathQuery::new_aggregate_count_on_range and TEST_LEAF
to locate where to add the transactional insert/delete and the paired
assertions.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@merk/src/proofs/query/aggregate_count.rs`:
- Around line 524-580: The code currently treats impossible mismatches as silent
undercounts; change both child-walk branches and the own_count computation to
fail fast: for the left/right walker, replace the if let Some(...) pattern with
a match on walker.walk(...) and if it returns None while the corresponding link
is present, propagate an error instead of skipping (use the same error
propagation mechanism as cost_return_on_error! to return a corrupted-state
error); likewise, after computing own_count =
node_count.saturating_sub(left_link_aggregate).saturating_sub(right_link_aggregate),
detect if node_count < left_link_aggregate + right_link_aggregate and return an
error rather than clamping — update the logic in walk_count_only / walker.walk
usage sites (functions/symbols: walker.walk, walk_count_only,
cost_return_on_error!, node_count, left_link_aggregate, right_link_aggregate,
total, range.contains(&node_key)) so callers no longer receive silently
truncated totals.

---

Nitpick comments:
In `@grovedb/src/tests/aggregate_count_query_tests.rs`:
- Around line 1443-1459: The test no_proof_uses_provided_transaction currently
starts the transaction after all data is committed, so change it to make the
transaction observe uncommitted state: after calling let tx =
db.start_transaction() perform a mutating operation inside that transaction
(e.g., insert or remove a key under the same path used by PathQuery via the
transaction API) that will change the expected aggregate count by ±1, then call
grove_db.query_aggregate_count(&path_query, Some(&tx), v) and assert the
returned count reflects the uncommitted change, and also call
grove_db.query_aggregate_count(&path_query, None, v) (or before the tx mutation)
to assert the base view does not include the change; use the existing symbols
tx, query_aggregate_count, PathQuery::new_aggregate_count_on_range and TEST_LEAF
to locate where to add the transactional insert/delete and the paired
assertions.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: f53d71ec-bfd9-40d0-9b76-c6194db3ce0f

📥 Commits

Reviewing files that changed from the base of the PR and between 1da6299 and 4f2820e.

📒 Files selected for processing (8)

• grovedb-version/src/version/grovedb_versions.rs
• grovedb-version/src/version/v1.rs
• grovedb-version/src/version/v2.rs
• grovedb-version/src/version/v3.rs
• grovedb/src/operations/get/query.rs
• grovedb/src/tests/aggregate_count_query_tests.rs
• merk/src/merk/prove.rs
• merk/src/proofs/query/aggregate_count.rs

[QuantumExplorer]

This is Claude — reply to @coderabbitai's review.

Nitpick on no_proof_uses_provided_transaction (test quality): addressed in 395b1e0. You were right that starting the transaction after all data is committed only proves Some(&tx) doesn't error, not that the transaction is actually threaded through to the merk read. The strengthened test now:

1. Reads the base count → asserts 10.
2. Inserts an in-range key ("k2") inside a transaction.
3. Asserts the transactional read sees 11 (uncommitted insert visible).
4. Asserts the non-transactional read still sees 10 (base view isolated).

This catches a regression where query_aggregate_count ignored its TransactionArg and read from the base view.

Both pieces of feedback (the major fail-fast change + this test) are in 395b1e0b. Inline reply to the major one is on the diff thread.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@QuantumExplorer The strengthened test design is exactly right — the before/after transaction isolation check (10 → 11 transactional, 10 non-transactional) creates a meaningful regression guard that would catch any TransactionArg being silently ignored. That's a much more robust proof of correctness than simply verifying Some(&tx) doesn't panic. Thanks for the thorough follow-up!

---

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!