feat(platform): add GetDocumentsCount and GetDocumentsSplitCount queries

[QuantumExplorer]

Summary

Adds two new gRPC endpoints for O(1)/O(log n) document counts on countable indexes (the documentsCountable / rangeCountable flags introduced in #2516):

• GetDocumentsCount — total count of documents matching where clauses
• GetDocumentsSplitCount — per-key counts split by an index property

Full stack from .proto → drive-abci handlers → rs-drive count machinery → proof verifier → rs-sdk Fetch traits → wasm-sdk + rs-sdk-ffi bindings, plus a book chapter explaining the design.

Layers touched

Layer	Package	What
Proto	dapi-grpc	Message definitions + RPC service entries
Codegen	dapi-grpc/build.rs	Register versioned request/response types
Server proxy	rs-dapi	drive_method! passthrough for both endpoints
Query handlers	rs-drive-abci	Version dispatch + v0 implementations (no-prove fast path + prove path)
Drive query	rs-drive	DriveDocumentCountQuery — count-tree walker, supports Equal and In operators
Proof verifier	rs-drive-proof-verifier	FromProof implementations for DocumentCount and DocumentSplitCounts
Rust SDK	rs-sdk	DocumentCountQuery / DocumentSplitCountQuery + Fetch impls
WASM SDK	wasm-sdk	getDocumentsCount / getDocumentsSplitCount (+ proof-info variants)
FFI	rs-sdk-ffi	C bindings for iOS / Swift
Versioning	rs-platform-version	Query version bounds
Docs	book/	New "Document Count Trees" chapter under Drive

Two paths under the hood

• prove=false (fast path) — DriveDocumentCountQuery walks the countable index level by level, doing point-lookups against CountTree elements. Single-prefix query → O(1); partial prefix → O(distinct values at the unbound levels). Supports Equal (one path) and In (cartesian fork over the listed values, deduped by serialized key); range operators are rejected upfront with a clear error since the current PathQuery model can't express the boundary walk.
• prove=true (proof path) — drive-abci returns a standard DriveDocumentQuery proof of the matching documents themselves (no signed-count primitive on the wire today). The client verifies and aggregates locally: documents.len() as u64 for total counts; per-key serialize_value_for_key-bucketed counts for split. Capped at u16::MAX matching documents per request to keep response size bounded — beyond that, callers must use the no-prove fast path with a covering countable index.

Notable fixes during review

• Split-count proof verifier was returning Some(BTreeMap::new()) for any verified result set. Replaced with a dedicated maybe_from_proof_with_split_property entry point that takes the split property explicitly and aggregates verified documents; the generic FromProof<DriveDocumentQuery> impl now errors loudly so a caller can't silently get an empty map.
• In deduplication — age in [30, 30] would visit the same subtree twice; serialized keys are now tracked in a BTreeSet before forking.
• SDK limit truncation — DocumentCountQuery / DocumentSplitCountQuery → DriveDocumentQuery now force limit = None. Fix applied at the SDK layer covers WASM (which defaulted DocumentQuery.limit to 100) plus FFI and direct rs-sdk callers.
• Server prove path bounded — handler now caps DriveDocumentQuery.limit at u16::MAX rather than clearing it, so a prove=true request can't materialize an unbounded document set.

Test plan

• cargo check --workspace clean
• cargo clippy --workspace --all-features -- -D warnings clean (toolchain 1.92)
• cargo fmt --all applied
• 30 new tests across the stack:
  • 12 in rs-drive (drive_document_count_query/tests.rs) — index pickers, Equal / In paths, range rejection, dedup, unique-countable-index regression
  • 5 + 6 in drive-abci handlers (document_count_query, document_split_count_query) — total/split + In + range-rejection + prove + empty cases
  • 3 + 4 in rs-sdk (document_count, document_split_count) — mock-fetch coverage
• All affected packages green (rs-drive lib: 3075 tests; drive-abci count + split-count handlers: 11 tests; drive-proof-verifier: 217 tests)
• CI macOS run-time fits in 30-min budget (re-run pending after a file-rename caused a one-time cache invalidation)

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Added getDocumentsCount API endpoint to retrieve document counts with optional proof generation.
  • Added getDocumentsSplitCount API endpoint to retrieve document counts split by a specified property with optional proof generation.
  • Extended platform client libraries across Java, Objective-C, Python, and Web/TypeScript to support the new endpoints.

• Tests

  • Added unit tests covering document count and split count queries with and without proof generation.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds platform RPCs for document counting (per-query and split-by-property), proto messages, server transport bindings, dAPI service handlers, Drive ABCI query implementations (v0) with tests, proof-verifier types, platform-version bounds, and generated client bindings across Java, Objective‑C, Python, and Web; also adds getMostRecentShieldedAnchor RPC and minor proto field.

Changes

Cohort / File(s)	Summary
Proto Definitions & Build packages/dapi-grpc/protos/platform/v0/platform.proto, packages/dapi-grpc/build.rs	Added RPCs getDocumentsCount / getDocumentsSplitCount and their request/response messages; also added getMostRecentShieldedAnchor and a small proto field change; updated build-time versioned request/response arrays to include new message types.
Rust Transport & dAPI Service packages/rs-dapi-client/src/transport/grpc.rs, packages/rs-dapi/src/services/platform_service/mod.rs	Added TransportRequest bindings and Platform service methods wiring new gRPC endpoints to drive-backed handlers.
Drive ABCI Query Modules packages/rs-drive-abci/src/query/document_count_query/..., packages/rs-drive-abci/src/query/document_split_count_query/..., packages/rs-drive-abci/src/query/mod.rs, packages/rs-drive-abci/src/query/service.rs	Added query dispatchers and V0 implementations: version validation, contract/type resolution, CBOR where parsing, query execution (with/without proof), split-by-property aggregation, metadata handling, and unit tests; registered submodules and added QueryService endpoints.
Proof Verifier (Rust) packages/rs-drive-proof-verifier/src/proof.rs, .../proof/document_count.rs, .../proof/document_split_count.rs, packages/rs-drive-proof-verifier/src/lib.rs	Added DocumentCount and DocumentSplitCounts types with FromProof implementations; re-exported new types from crate root.
Platform Versioning & Mocks packages/rs-platform-version/src/version/.../mod.rs, .../v1.rs, .../mocks/v2_test.rs	Added document_count_query and document_split_count_query FeatureVersionBounds to version structs/constants and test mocks (initialized to 0).
Client Bindings — Java packages/dapi-grpc/clients/platform/v0/java/org/dash/platform/dapi/v0/PlatformGrpc.java	Generated Java gRPC stubs/server skeleton additions for getDocumentsCount, getDocumentsSplitCount, getMostRecentShieldedAnchor; updated method descriptors, stubs, and service descriptor.
Client Bindings — Objective‑C packages/dapi-grpc/clients/platform/v0/objective-c/Platform.pbobjc.{h,m}, .../Platform.pbrpc.{h,m}	Added Objective‑C protobuf classes and gRPC client/server methods for document count and split-count RPCs and most-recent-shielded-anchor; added proto message classes and updated doc annotations and method declarations.
Client Bindings — Python packages/dapi-grpc/clients/platform/v0/python/platform_pb2_grpc.py	Added server and stub methods and server registration for new RPCs; updated docstrings.
Client Bindings — Web/TS/JS packages/dapi-grpc/clients/platform/v0/web/platform_pb.d.ts, .../platform_pb_service.d.ts, .../platform_pb_service.js	Added TypeScript definitions and JS service/client methods/descriptors for new RPCs and updated web protobuf types (including split-count structures and small request field addition).

Sequence Diagram(s)

sequenceDiagram
participant Client
participant gRPCTransport as gRPC Transport
participant PlatformService
participant QueryHandler as Query Handler
participant Drive
participant Verifier as Proof Verifier
Client->>gRPCTransport: GetDocumentsCountRequest
gRPCTransport->>PlatformService: route request
PlatformService->>QueryHandler: query_documents_count()
QueryHandler->>QueryHandler: validate version & bounds
QueryHandler->>Drive: query_documents_count_v0()
Drive->>Drive: resolve contract/type, parse where
alt prove = true
Drive->>Drive: execute with proof
Drive->>QueryHandler: return proof + metadata
QueryHandler->>Verifier: verify proof & checkpoint
Verifier->>QueryHandler: verification result
else prove = false
Drive->>Drive: execute query, count results
Drive->>QueryHandler: return count + metadata
end
QueryHandler->>PlatformService: GetDocumentsCountResponse
PlatformService->>gRPCTransport: response
gRPCTransport->>Client: GetDocumentsCountResponse

Loading

sequenceDiagram
participant Client
participant gRPCTransport as gRPC Transport
participant PlatformService
participant QueryHandler as Query Handler
participant Drive
participant Verifier as Proof Verifier
Client->>gRPCTransport: GetDocumentsSplitCountRequest
gRPCTransport->>PlatformService: route request
PlatformService->>QueryHandler: query_documents_split_count()
QueryHandler->>QueryHandler: validate version & bounds
QueryHandler->>Drive: query_documents_split_count_v0()
Drive->>Drive: resolve contract/type, validate split property, parse where
alt prove = true
Drive->>Drive: execute with proof
Drive->>QueryHandler: return proof + metadata
QueryHandler->>Verifier: verify proof & checkpoint
Verifier->>QueryHandler: verification result
else prove = false
Drive->>Drive: execute query, fetch docs
Drive->>Drive: group counts by property value
Drive->>QueryHandler: return SplitCountEntry list + metadata
end
QueryHandler->>PlatformService: GetDocumentsSplitCountResponse
PlatformService->>gRPCTransport: response
gRPCTransport->>Client: GetDocumentsSplitCountResponse

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Poem

🐇 I counted bytes and grouped by key,
Hopped through proofs and proto tree.
From request to root, I stitched the chain,
Split counts and totals, all in my lane.
A happy hop — the queries reign!

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 68.18% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically summarizes the main changes: adding two new gRPC query endpoints (GetDocumentsCount and GetDocumentsSplitCount) for document counting functionality, which is the primary objective of this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ 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 feat/documents-count-query

---

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.}

[thepastaclaw]

Review Gate

Commit: 86b9bbc6

• ⏳ Debounce: 13m ago (need 30m)

• ⏳ CI checks: checks still running (1 pending)

• ✅ CodeRabbit review: comment found

• ✅ Off-peak hours: off-peak (06:27 AM PT Saturday)

• Run review now (check to override)

[codecov]

Codecov Report

❌ Patch coverage is 79.01399% with 315 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.27%. Comparing base (ba3b05d) to head (86b9bbc).

Files with missing lines	Patch %	Lines
...-drive/src/query/drive_document_count_query/mod.rs	84.05%	70 Missing ⚠️
...e-proof-verifier/src/proof/document_split_count.rs	20.77%	61 Missing ⚠️
...bci/src/query/document_split_count_query/v0/mod.rs	91.61%	38 Missing ⚠️
...rive-abci/src/query/document_count_query/v0/mod.rs	90.33%	37 Missing ⚠️
...e-abci/src/query/document_split_count_query/mod.rs	0.00%	37 Missing ⚠️
...s-drive-abci/src/query/document_count_query/mod.rs	0.00%	32 Missing ⚠️
...s-drive-proof-verifier/src/proof/document_count.rs	0.00%	27 Missing ⚠️
...s-dpp/src/data_contract/document_type/index/mod.rs	56.00%	11 Missing ⚠️
..._for_index_level_for_contract_operations/v0/mod.rs	50.00%	2 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## v3.1-dev #3435 +/- ##
============================================
- Coverage 88.32% 88.27% -0.05% 
============================================
Files 2486 2493 +7 Lines 302964 304434 +1470 ============================================
+ Hits 267593 268750 +1157 - Misses 35371 35684 +313 

Components	Coverage Δ
dpp	87.99% <75.55%> (-0.02%)	⬇️
drive	87.41% <83.89%> (-0.02%)	⬇️
drive-abci	90.18% <84.08%> (-0.07%)	⬇️
sdk	∅ <ø> (∅)
dapi-client	∅ <ø> (∅)
platform-version	∅ <ø> (∅)
platform-value	92.17% <ø> (ø)
platform-wallet	∅ <ø> (∅)
drive-proof-verifier	54.22% <15.38%> (-1.45%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

Actionable comments posted: 5

🧹 Nitpick comments (1)

packages/rs-drive-proof-verifier/src/proof/document_count.rs (1)

16-18: Remove the unnecessary Clone bound and request clone.
request is consumed by try_into and not reused, so Q: Clone and request.clone() can be dropped.

Refactor suggestion

 impl<'dq, Q> FromProof<Q> for DocumentCount
where
- Q: TryInto<DriveDocumentQuery<'dq>> + Clone + 'dq,+ Q: TryInto<DriveDocumentQuery<'dq>> + 'dq,
Q::Error: std::fmt::Display,
{
@@
- let request: DriveDocumentQuery<'dq> =- request- .clone()- .try_into()+ let request: DriveDocumentQuery<'dq> =+ request+ .try_into()
.map_err(|e: Q::Error| Error::RequestError {
error: e.to_string(),
})?;

Also applies to: 35-39

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.
In `@packages/rs-drive-proof-verifier/src/proof/document_count.rs` around lines 16
- 18, Remove the unnecessary Clone bound on the generic Q and stop cloning the
request before conversion: in the function signatures where you have Q:
TryInto<DriveDocumentQuery<'dq>> + Clone + 'dq (and the similar signature around
line 35-39), drop the + Clone requirement and remove any request.clone() calls;
call request.try_into() (or std::convert::TryInto::try_into(request)) directly
since try_into consumes request and no further clones are needed. Ensure the
Q::Error: std::fmt::Display bound remains if used for error formatting.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/rs-drive-abci/src/query/document_count_query/v0/mod.rs`:
- Around line 73-84: The count endpoint is incorrectly capped because
DriveDocumentQuery::from_decomposed_values is called with
Some(self.config.drive.default_query_limit) which embeds a size limit into the
query; change that argument to None so the constructed DriveDocumentQuery
(created in the drive_query variable in mod.rs) does not pass a limit into
SizedQuery and GroveDB, ensuring the subsequent count computed from
results.len() reflects all matching documents; update any related comments and,
if you prefer truncation semantics instead, add explicit response metadata
indicating the result was truncated rather than leaving the limit in place.
In `@packages/rs-drive-abci/src/query/document_split_count_query/v0/mod.rs`:
- Around line 101-112: The split count query is using a hard limit
(Some(self.config.drive.default_query_limit)) which truncates results and yields
incorrect split counts; update the DriveDocumentQuery::from_decomposed_values
call (the drive_query creation) to remove the default_query_limit by passing no
limit (e.g., None) so the query returns the full result set for accurate split
counting, ensuring you only change the limit argument and keep the other
parameters the same.
- Around line 164-172: The current code silently swallows CBOR serialization
failures by using value.to_cbor_buffer().unwrap_or_default(), which can collapse
distinct property values into the same empty key; change this to propagate the
error instead of defaulting: replace the unwrap_or_default call in the let key
assignment (where you access document.properties() and
split_count_by_index_property) with proper error handling (e.g., use
value.to_cbor_buffer()? or value.to_cbor_buffer().map_err(|e| /* wrap in the
function's error type */ )?) so that serialization failures return an error from
the surrounding function rather than producing an empty Vec<u8>.
In `@packages/rs-drive-proof-verifier/src/proof/document_split_count.rs`:
- Around line 49-63: The code currently discards the verified documents from
request.verify_proof and always returns an empty DocumentSplitCounts; change
verify_proof usage to keep the deserialized documents, compute split counts
using the request's split_count_by_index_property (or the equivalent field on
the DriveDocumentQuery) and a helper like split_count_by_index_property to group
documents and produce a BTreeMap, then return DocumentSplitCounts(populated_map)
along with mtd.clone() and proof.clone(); ensure you reference and use the
returned _documents from request.verify_proof and mirror the approach used in
document_count.rs where documents.len() is extracted from the verified proof.
In
`@packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_query_versions/mod.rs`:
- Around line 11-12: DriveAbciQueryVersions struct literals in the mocks need to
be updated to include the two new mandatory fields document_count_query and
document_split_count_query; locate the initializer in
packages/rs-platform-version/src/version/mocks/v2_test.rs (the mock
DriveAbciQueryVersions instance around Line ~170) and add those fields with
appropriate FeatureVersionBounds values (e.g., the same bounds used for similar
query fields or FeatureVersionBounds::default()) so the struct literal compiles;
ensure the field names exactly match
DriveAbciQueryVersions::document_count_query and ::document_split_count_query.
---
Nitpick comments:
In `@packages/rs-drive-proof-verifier/src/proof/document_count.rs`:
- Around line 16-18: Remove the unnecessary Clone bound on the generic Q and
stop cloning the request before conversion: in the function signatures where you
have Q: TryInto<DriveDocumentQuery<'dq>> + Clone + 'dq (and the similar
signature around line 35-39), drop the + Clone requirement and remove any
request.clone() calls; call request.try_into() (or
std::convert::TryInto::try_into(request)) directly since try_into consumes
request and no further clones are needed. Ensure the Q::Error: std::fmt::Display
bound remains if used for error formatting.

🪄 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: 7d1a82c8-31c5-47f1-8fa3-922c9cbf1a3d

📥 Commits

Reviewing files that changed from the base of the PR and between 8a83981 and 0c84b98.

📒 Files selected for processing (15)

• packages/dapi-grpc/build.rs
• packages/dapi-grpc/protos/platform/v0/platform.proto
• packages/rs-dapi-client/src/transport/grpc.rs
• packages/rs-dapi/src/services/platform_service/mod.rs
• packages/rs-drive-abci/src/query/document_count_query/mod.rs
• packages/rs-drive-abci/src/query/document_count_query/v0/mod.rs
• packages/rs-drive-abci/src/query/document_split_count_query/mod.rs
• packages/rs-drive-abci/src/query/document_split_count_query/v0/mod.rs
• packages/rs-drive-abci/src/query/mod.rs
• packages/rs-drive-abci/src/query/service.rs
• packages/rs-drive-proof-verifier/src/proof.rs
• packages/rs-drive-proof-verifier/src/proof/document_count.rs
• packages/rs-drive-proof-verifier/src/proof/document_split_count.rs
• packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_query_versions/mod.rs
• packages/rs-platform-version/src/version/drive_abci_versions/drive_abci_query_versions/v1.rs

[coderabbitai]

🧹 Nitpick comments (3)

packages/rs-drive-abci/src/query/document_count_query/v0/mod.rs (2)

73-90: Construct the unlimited count query directly.

Line 77 sets a default limit and Line 89 immediately removes it. Passing None for limit at construction avoids mutable post-fix state and reduces regression risk.

♻️ Proposed simplification

- let mut drive_query =+ let drive_query =
check_validation_result_with_data!(DriveDocumentQuery::from_decomposed_values(
where_clause,
None,
- Some(self.config.drive.default_query_limit),+ None,
None,
true,
None,
contract_ref,
document_type,
&self.config.drive,
));
-- // Remove the limit so we count ALL matching documents, not just up to the- // default query limit. A count query needs to return the total number of- // documents matching the where clause.- drive_query.limit = None;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.
In `@packages/rs-drive-abci/src/query/document_count_query/v0/mod.rs` around lines
73 - 90, The code currently constructs a DriveDocumentQuery with
Some(self.config.drive.default_query_limit) and then mutates drive_query.limit =
None; instead, call DriveDocumentQuery::from_decomposed_values with None for the
limit parameter so the query is constructed without any limit upfront; update
the call site (DriveDocumentQuery::from_decomposed_values) to pass None instead
of Some(self.config.drive.default_query_limit) and remove the subsequent
drive_query.limit = None mutation.

---

152-160: Use one platform version source per test.

These tests mix PlatformVersion::latest() with version from setup_platform. Using a single source (preferably version) makes tests less brittle across versioned behavior changes.

🧪 Example adjustment pattern

- let platform_version = PlatformVersion::latest();+ let platform_version = version;

Apply consistently in the three tests where documents/contracts are created and stored.

Also applies to: 171-175, 181-182, 213-221, 257-265, 276-280, 286-287

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.
In `@packages/rs-drive-abci/src/query/document_count_query/v0/mod.rs` around lines
152 - 160, The tests call PlatformVersion::latest() directly when creating
contracts/documents (e.g., in json_document_to_contract_with_ids) while the test
harness provides a platform version variable (commonly named version from
setup_platform); change all uses of PlatformVersion::latest() in those tests to
use the single source 'version' instead so the tests rely on the
setup_platform-provided version consistently (apply this replacement in the
calls to json_document_to_contract_with_ids and any other contract/document
creation or storage sites mentioned around the blocks using
PlatformVersion::latest()).

packages/rs-drive-abci/src/query/document_split_count_query/v0/mod.rs (1)

101-117: Consider passing None directly for the limit parameter.

The code passes Some(self.config.drive.default_query_limit) on line 105, then immediately removes the limit on line 117. This two-step approach is redundant - you could simplify by passing None directly.

♻️ Proposed simplification

 let mut drive_query =
check_validation_result_with_data!(DriveDocumentQuery::from_decomposed_values(
where_clause,
None,
- Some(self.config.drive.default_query_limit),+ None, // No limit - split count needs all matching documents
None,
true,
None,
contract_ref,
document_type,
&self.config.drive,
));
- // Remove the limit so we count ALL matching documents, not just up to the- // default query limit. A split count query needs to return complete counts- // across all values of the split property.- drive_query.limit = None;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.
In `@packages/rs-drive-abci/src/query/document_split_count_query/v0/mod.rs` around
lines 101 - 117, DriveDocumentQuery::from_decomposed_values is being called with
Some(self.config.drive.default_query_limit) and then immediately overwritten by
setting drive_query.limit = None, which is redundant; update the call to
DriveDocumentQuery::from_decomposed_values to pass None for the limit parameter
(the argument currently supplying default_query_limit) and remove the subsequent
drive_query.limit = None line so the query is created without a limit from the
start.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@packages/rs-drive-abci/src/query/document_count_query/v0/mod.rs`:
- Around line 73-90: The code currently constructs a DriveDocumentQuery with
Some(self.config.drive.default_query_limit) and then mutates drive_query.limit =
None; instead, call DriveDocumentQuery::from_decomposed_values with None for the
limit parameter so the query is constructed without any limit upfront; update
the call site (DriveDocumentQuery::from_decomposed_values) to pass None instead
of Some(self.config.drive.default_query_limit) and remove the subsequent
drive_query.limit = None mutation.
- Around line 152-160: The tests call PlatformVersion::latest() directly when
creating contracts/documents (e.g., in json_document_to_contract_with_ids) while
the test harness provides a platform version variable (commonly named version
from setup_platform); change all uses of PlatformVersion::latest() in those
tests to use the single source 'version' instead so the tests rely on the
setup_platform-provided version consistently (apply this replacement in the
calls to json_document_to_contract_with_ids and any other contract/document
creation or storage sites mentioned around the blocks using
PlatformVersion::latest()).
In `@packages/rs-drive-abci/src/query/document_split_count_query/v0/mod.rs`:
- Around line 101-117: DriveDocumentQuery::from_decomposed_values is being
called with Some(self.config.drive.default_query_limit) and then immediately
overwritten by setting drive_query.limit = None, which is redundant; update the
call to DriveDocumentQuery::from_decomposed_values to pass None for the limit
parameter (the argument currently supplying default_query_limit) and remove the
subsequent drive_query.limit = None line so the query is created without a limit
from the start.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 960f7945-798d-456b-b54c-622573fc270f

📥 Commits

Reviewing files that changed from the base of the PR and between 0c84b98 and b878c55.

📒 Files selected for processing (3)

• packages/rs-drive-abci/src/query/document_count_query/v0/mod.rs
• packages/rs-drive-abci/src/query/document_split_count_query/v0/mod.rs
• packages/rs-platform-version/src/version/mocks/v2_test.rs

[thepastaclaw]

Code Review

Well-structured new query endpoints following existing patterns. One confirmed bug: the DocumentSplitCountsFromProof implementation verifies the GroveDB proof but returns BTreeMap::new() instead of extracting the actual count data. Any client using prove=true for split-count queries receives a valid-looking but empty result. Convergent finding from two independent codex agents (rust-quality + security-auditor), confirmed by verifier.

Reviewed commit: 99686a3

🔴 1 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-drive-proof-verifier/src/proof/document_split_count.rs`:
- [BLOCKING] line 60: DocumentSplitCounts FromProof always returns empty BTreeMap
The `FromProof` implementation for `DocumentSplitCounts` verifies the GroveDB proof and Tenderdash proof but discards the verified documents (`_documents` on line 49) and returns `BTreeMap::new()` on line 60. The `prove=false` server-side path (`document_split_count_query/v0/mod.rs:154-180`) correctly deserializes documents and groups counts by the split property, but this client-side proof verification path never performs the equivalent aggregation.
Any client using `prove=true` for split-count queries receives `Some(DocumentSplitCounts(BTreeMap::new()))` — a valid-looking but empty result. The verified documents need to be grouped by the split property and counted, matching the server-side logic.

[thepastaclaw]

Code Review

This push is an incremental re-review of PR #3435 at commit 8ffbf55a. The new commit only regenerates dapi-grpc client artifacts and removes a stale // Force rebuild comment from build.rs, so the previously reported proof-verifier bug is the main question. That blocker is still present in the current snapshot: the DocumentSplitCounts proof path verifies the proof but still discards the verified documents and returns an empty map.

Reviewed commit: 8ffbf55

🔴 1 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-drive-proof-verifier/src/proof/document_split_count.rs`:
- [BLOCKING] lines 49-60: prove=true split-count verification still returns an empty result
This re-review commit does not touch the split-count proof verifier, and the same bug is still present in the current snapshot. `verify_proof()` returns the verified documents into `_documents` on lines 49-51, but the implementation immediately discards them and returns `DocumentSplitCounts(BTreeMap::new())` on line 60. The server-side non-proof path in `rs-drive-abci` groups matching documents by the split property and returns counts, so `prove=true` and `prove=false` still diverge semantically: a valid proof-backed split-count query succeeds but always produces an empty map. This means the new generated client bindings now expose an endpoint whose proof-verification path still cannot return correct split counts.

[thepastaclaw]

Code Review

Incremental re-review of PR #3435 at commit 8c5d2b4f. This push only updates Cargo.lock to pin libz-sys (plus lockfile-adjacent version churn such as semver and arc-swap), so the key question is whether the previously reported split-count proof bug was fixed elsewhere. It was not: the DocumentSplitCounts proof verifier still discards the verified documents and returns an empty map, so prove=true split-count queries are still incorrect in the current tip.

Reviewed commit: 8c5d2b4

🔴 1 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-drive-proof-verifier/src/proof/document_split_count.rs`:
- [BLOCKING] lines 49-60: The split-count proof verifier still drops the verified result set
This incremental push does not touch the split-count verifier, and the same blocker remains in the current tip. `request.verify_proof()` returns the verified documents into `_documents` on lines 49–51, but the implementation then ignores them and returns `DocumentSplitCounts(BTreeMap::new())` on line 60. The non-proof server path in `rs-drive-abci/src/query/document_split_count_query/v0/mod.rs` groups matching documents by the split property and returns actual counts, so `prove=true` and `prove=false` still diverge semantically: a valid proof-backed split-count query succeeds but always yields an empty map. The lockfile pin in this commit may help CI, but it does not make the new split-count endpoint correct.

[thepastaclaw]

Code Review

This push rewrites the non-proof count paths to use CountTree-based aggregation, but it introduces a correctness regression: the fast path only applies equality predicates and silently ignores all other where operators. That makes prove=false return broader counts than prove=true for range/prefix-style queries. The previously reported DocumentSplitCounts proof-verifier bug is also still present, so both the proof and non-proof split-count paths remain incorrect in the current tip.

Reviewed commit: e7c98f8

🔴 3 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-drive-abci/src/query/document_count_query/v0/mod.rs`:
- [BLOCKING] lines 152-165: The CountTree fast path silently drops non-equality filters
The new `prove=false` path chooses a countable index from `all_where_clauses`, but `find_countable_index_for_where_clauses()` only looks at clauses whose operator is `WhereOperator::Equal` (lines 198-202), and `count_from_count_tree()` likewise only serializes equality clauses into the path (lines 275-289). Any other predicate in the request (`>`, `>=`, `<`, `startsWith`, etc.) is neither validated nor applied. As a result, a query like `where = [["age", ">", 18]]` can still hit the CountTree path and return the count for the entire prefix / whole index instead of the filtered subset, while the `prove=true` path above still evaluates the full `DriveDocumentQuery`. `prove=false` and `prove=true` therefore diverge semantically for the same request. The no-proof path needs to reject unsupported operators or fall back to the full query engine whenever any non-equality clause is present.
In `packages/rs-drive-abci/src/query/document_split_count_query/v0/mod.rs`:
- [BLOCKING] lines 175-189: The split-count CountTree path also ignores non-equality where clauses
The same issue exists in the split-count refactor. `find_countable_index_for_split()` builds its prefix using only `WhereOperator::Equal` clauses (lines 221-225, 232-249), and `split_count_from_count_tree()` only pushes equality values into the CountTree path (lines 290-303). Any non-equality predicate in the request is silently ignored rather than rejected or evaluated. That means `prove=false` split counts can now be computed over the entire split subtree even when the original query included additional range/pattern filters, while the `prove=true` path still uses the full `DriveDocumentQuery`. This breaks correctness for non-equality split-count queries and makes proof/no-proof results disagree.
In `packages/rs-drive-proof-verifier/src/proof/document_split_count.rs`:
- [BLOCKING] lines 49-60: The proof-backed split-count verifier still returns an empty map
The previously reported proof-verifier bug is still present in this tip. `request.verify_proof()` returns the verified documents into `_documents` on lines 49-51, but the implementation immediately discards them and returns `DocumentSplitCounts(BTreeMap::new())` on line 60. So even after this refactor, a valid `prove=true` split-count query still verifies the proof and then returns an empty result instead of grouping the verified documents by the split property. This keeps the proof-backed endpoint incorrect even if the non-proof path were fixed.

[thepastaclaw]

Code Review

Incremental re-review of PR #3435 at commit 1c23a28c. This push moves the CountTree counting logic from rs-drive-abci into a shared rs-drive::query::DriveDocumentCountQuery, but it does not fix the correctness issues from the previous review. The new shared implementation still only honors equality clauses in the no-proof path, so unsupported operators are silently ignored, and the proof-backed split-count verifier still returns an empty map.

Reviewed commit: 1c23a28

🔴 3 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-drive/src/query/drive_document_count_query.rs`:
- [BLOCKING] lines 69-111: The shared CountTree total-count path still ignores non-equality filters
`find_countable_index_for_where_clauses()` now lives in `rs-drive`, but it still builds `equality_fields` by discarding every where clause whose operator is not `WhereOperator::Equal` (lines 73-76). `execute_total_count()` then only serializes equality clauses into the index path (lines 199-218) and never validates that there were additional predicates in the original query. That means a request with mixed filters like `["age", ">", 18]` or `["name", "startsWith", "A"]` can still take the no-proof CountTree fast path and return the broader prefix count / full index count, while the `prove=true` path above still uses the full `DriveDocumentQuery`. So the refactor preserved the bug where `prove=false` silently ignores non-equality constraints instead of rejecting them or falling back to the full query engine.
- [BLOCKING] lines 118-145: The shared split-count path still drops non-equality where clauses
`find_countable_index_for_split()` has the same problem in the shared implementation: it only considers `WhereOperator::Equal` clauses when choosing an index (lines 121-124), and `execute_split_count()` only pushes equality values into the path before enumerating split buckets (lines 263-285). Any other predicate in the original query is silently ignored rather than enforced. As a result, `prove=false` split-count queries can still return counts for the whole split subtree even when the request included additional range/pattern filters, while `prove=true` uses the full query semantics. Moving the code from `rs-drive-abci` into `rs-drive` did not fix the correctness gap; it just centralized it.
In `packages/rs-drive-proof-verifier/src/proof/document_split_count.rs`:
- [BLOCKING] lines 49-60: The proof-backed split-count verifier still returns an empty map
The old proof-verifier bug is unchanged in this tip. `request.verify_proof()` still returns the verified documents into `_documents` on lines 49-51, but the implementation immediately discards them and returns `DocumentSplitCounts(BTreeMap::new())` on line 60. So even after the CountTree refactor, a valid `prove=true` split-count query still verifies the proof and then returns an empty result instead of grouping the verified documents by the split property.

[thepastaclaw]

Code Review

The workflow change is syntactically fine, but it only partially fixes the intended test-trigger problem because the new Dashmate-specific gate is narrower than the existing integration trigger surface for the same jobs.

Reviewed commit: 998fdbb

🔴 1 blocking

1 additional finding

🔴 blocking: New `dashmate-changed` gate still leaves the same integration jobs blind to non-Dashmate trigger paths

.github/workflows/tests.yml (lines 128-168)

Validated against the checked-out workflow plus .github/package-filters/test-suite-triggers.yml: the new dashmate-changed output only matches packages/dashmate/**, but it now gates build-images, dashmate-e2e-tests, test-suite, and test-functional. Those same jobs are still part of the broader integration surface already described by test-suite-triggers.yml, which includes paths such as packages/platform-test-suite/**, .github/actions/local-network/**, scripts/**, and multiple platform package directories. After this patch, a PR that changes those integration-critical paths but not packages/dashmate/** will still skip these jobs, so the workflow blind spot remains and the fix is incomplete.

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `.github/workflows/tests.yml`:
- [BLOCKING] lines 128-168: New `dashmate-changed` gate still leaves the same integration jobs blind to non-Dashmate trigger paths
Validated against the checked-out workflow plus `.github/package-filters/test-suite-triggers.yml`: the new `dashmate-changed` output only matches `packages/dashmate/**`, but it now gates `build-images`, `dashmate-e2e-tests`, `test-suite`, and `test-functional`. Those same jobs are still part of the broader integration surface already described by `test-suite-triggers.yml`, which includes paths such as `packages/platform-test-suite/**`, `.github/actions/local-network/**`, `scripts/**`, and multiple platform package directories. After this patch, a PR that changes those integration-critical paths but not `packages/dashmate/**` will still skip these jobs, so the workflow blind spot remains and the fix is incomplete.

[github-actions]

✅ DashSDKFFI.xcframework built for this PR.

• Workflow run: https://github.com/dashpay/platform/actions/runs/25602013645
• Artifacts: DashSDKFFI.xcframework (folder), DashSDKFFI.xcframework.zip, xc_checksum.txt

SwiftPM (host the zip at a stable URL, then use):

.binaryTarget(
name:"DashSDKFFI",
url:"https://your.cdn.example/DashSDKFFI.xcframework.zip",
checksum:"b894d1b6daab5bb0fc91757e9cfb8d522ee8b3338001b24e6473e3126fa70f8b")

Xcode manual integration:

• Download 'DashSDKFFI.xcframework' artifact from the run link above.
• Drag it into your app target (Frameworks, Libraries & Embedded Content) and set Embed & Sign.
• If using the Swift wrapper package, point its binaryTarget to the xcframework location or add the package and place the xcframework at the expected path.

[github-actions]

📖 Book Preview built successfully.

Download the preview from the workflow artifacts.
To view locally: download the artifact, unzip, and open index.html.

Updated at 2026-05-09T13:14:07.841Z

[QuantumExplorer]

I’m Codex, posting the review findings I found while checking this PR.

Findings

1. [P1] Count proof path is unbounded

   packages/rs-drive-abci/src/query/document_count_query/v0/mod.rs:104

   The prove=true path builds a normal DriveDocumentQuery, then clears its limit before generating the proof. That makes a public count request materialize/prove every matching document instead of proving the count tree, bypassing max-return limits and making empty-where count requests potentially huge. The split-count handler does the same. Use the CountTree proof path, keep a hard bound, or reject prove=true until count-tree proof verification exists.

2. [P1] WASM count inherits document limit

   packages/wasm-sdk/src/queries/document.rs:462

   The WASM count methods reuse parse_documents_query, which sets a default document limit of 100. The server proof is generated with no limit, but the SDK verifier converts this same request back into a DriveDocumentQuery and DocumentCount counts the verified documents, so getDocumentsCount / getDocumentsSplitCount can be capped or mismatched by the document-query limit. Count queries should build a base query with limit=0 / None and ignore any document pagination fields.

3. [P2] Duplicate IN values double-count

   packages/rs-drive/src/query/drive_document_count_query.rs:361

   For IN clauses the count code iterates every value and sums each branch. A query like age in [30, 30] will count the same subtree twice, and split-count does the same when merging branches. IN semantics are set-membership, so serialize/deduplicate the branch keys before summing.

4. [P2] Unique countable indexes return zero

   packages/rs-drive/src/query/drive_document_count_query.rs:624

   fetch_count_at_path assumes key [0] is a CountTree and reads count_value_or_default(). For countable unique indexes, existing index insertion stores the terminal reference directly at key [0] inside the count tree, so this returns 0 for a matching unique value instead of 1. Handle unique indexes separately or read the parent count tree count rather than the terminal reference.

[QuantumExplorer]

Thanks Codex — reviewed all four findings, fixed three, dismissed one as a non-issue. Addressed in commit 4ef1e40.

[P1] Count proof path is unbounded — fixed (defensive bound)

The handlers now cap the prove-path DriveDocumentQuery at u16::MAX matching documents rather than clearing the limit:

drive_query.limit = Some(u16::MAX);

This is a defensive bound, not the proper fix. The proper fix is count-tree proof verification (no signed-count primitive exists on the wire today), which is out of scope for this PR. Callers that need exact counts above u16::MAX use prove=false with a covering countable index. Documented in book/src/drive/document-count-trees.md.

[P1] WASM count inherits document limit — fixed at the SDK layer

Both DocumentCountQuery and DocumentSplitCountQueryTryFrom<&Self> for DriveDocumentQuery now force limit = None:

letmut drive_query:DriveDocumentQuery = (&query.document_query).try_into()?;
drive_query.limit = None;Ok(drive_query)

The proof verifier counts documents from the verified proof, so any limit on the wrapped DocumentQuery would truncate the count. Fixing it in the rs-sdk conversion layer covers WASM, FFI, and direct rs-sdk callers in one place rather than each entry point setting limit = 0 defensively.

[P2] Duplicate IN values double-count — fixed

expand_paths_and_count and expand_split_prefix_paths now serialize each In value to the canonical index key and dedupe via a BTreeSet<Vec<u8>> before forking:

letmut seen_keys:BTreeSet<Vec<u8>> = BTreeSet::new();for v in values {let serialized = self.document_type.serialize_value_for_key(...)?;if !seen_keys.insert(serialized.clone()){continue;}// ... recurse / collect}

Regression test: test_count_query_in_operator_dedupes_duplicate_values (asserts age in [30, 30, 30] over 2 docs with age=30 returns 2, not 6).

[P2] Unique countable indexes return zero — verified, not a bug

I wrote a test (test_count_query_unique_countable_index_returns_correct_count) that inserts 3 distinct (firstName, middleName, lastName) tuples into a contract whose 3-property index has unique: true, countable: true, then queries for an exact match. The test passes — count is 1, not 0.

The reason: grovedb-element's Element::count_value_or_default() returns 1 for any non-CountTree variant (the _ => 1 arm of the match). The Reference stored at key [0] under a unique countable index falls into that arm, so fetch_count_at_path returns 1 correctly. From grovedb-element/src/element/helpers.rs:

pubfncount_value_or_default(&self) -> u64{matchself{Element::CountTree(_, count_value, _)
| Element::CountSumTree(_, count_value, ..)
| Element::ProvableCountTree(_, count_value, _)
| Element::ProvableCountSumTree(_, count_value, ..) => *count_value,
_ => 1,}}

Kept the test as a regression guard so this stays correct.

cc @QuantumExplorer

[QuantumExplorer]

There will need to be a follow up to this PR, but for now am merging it in.