feat(drive)!: timeRange buckets on indexOnly indexes - #4508
Merged
Conversation
Contributor
|
Warning Review limit reachedNext included review available in 28 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
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. Comment |
Contributor
|
📖 Book Preview built successfully. Download the preview from the workflow artifacts. Updated at 2026-08-28T13:05:56.218Z |
Collaborator
|
🕓 Ready for review — 1 ahead in queue (commit dac8758) |
Lift the parser rejection of timeRange on indexOnly indexes. A bucketed indexOnly index writes one commitment entry per containing bucket under the grid-qualified level, exactly as stored types do — the walkers' bucket fan-out, the IN_TIME_RANGE resolution/admission machinery, and the count aggregate surfaces are all shared and unchanged. - dpp: remove the rejection; no new source rule is needed — the shared timeRange rules force a required system timestamp as the first property, and the indexOnly prefix rule admits only $ownerId and $createdAt, which pins the source to $createdAt. A bucketed index involves $createdAt, so it never counts as the required $createdAt-free proof index, and delete-by-values stays deterministic (the carried $createdAt reproduces the bucket set). - probes: the entry path derivation becomes plural (index_only_entry_paths_and_key) — level segments through Index::level_key and bucket value keys through entry_keys_for_raw, the same derivation the walkers write with. The delete-side commitment probe requires ALL bucket entries to match; the create-side duplicate probe fires on ANY existing entry. - read surface: document synthesis over a bucketed indexOnly index is refused with guidance (the bucket level carries bucket-start granularity, not the document's timestamp) — guarded in both the route and the synthesis index resolution so prover, no-proof executor and verifier refuse alike; the terminal-clause matcher excludes bucketed indexes so a raw query never walks grid-keyed levels; the from-values proof builder rejects bucketed indexes defensively. - estimation: the per-entry item padding rises 16 → 32 bytes — the documented per-entry-chain under-count exceeded the old pad once the bucket fan-out removed the slack other levels contribute; the pad is per entry so it scales with the fan-out. The indexOnly 0-tree's stateless apply now also claims the real value-tree parent type. - fixture/tests: yappr beat doctype (byHourHashtag bucketed on a 3600s/900s grid with the count axes; byHashtag as the proof index). E2e pins: one entry per bucket at arithmetic-pinned starts, resolved IN_TIME_RANGE bucket counts (unproved + proved parity), synthesis refusal, delete removing every bucket entry + falsified-timestamp refusal, estimation upper bounds, duplicate/overlap semantics; abci lifecycle with executed create/delete proofs through the non-bucketed proof index. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
QuantumExplorer
force-pushed
the
feat/index-only-time-range-buckets
branch
from
August 28, 2026 13:05
b094b81 to
dac8758
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## v4.2-dev #4508 +/- ##
============================================
+ Coverage 82.66% 83.24% +0.57%
============================================
Files 2744 2773 +29
Lines 370075 374003 +3928
============================================
+ Hits 305916 311325 +5409
+ Misses 64159 62678 -1481
🚀 New features to boost your workflow:
|
Member
Author
|
Reviewed |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue being fixed or feature implemented
Stacked on #4506— #4506 merged; this PR is now rebased directly ontov4.2-dev(single commit, its own diff only).The second protocol-scale indexOnly extension: timeRange buckets. "Trending under #dash this hour" needs likes bucketed by creation time — #3740 shipped exactly this for stored types, but the indexOnly parser rejected
timeRangewith "not yet supported".What was done?
Nearly everything composes from #3740 + the indexOnly stack; the walkers' bucket fan-out,
IN_TIME_RANGEresolution/admission, and the count aggregate surfaces are shared and unchanged:$ownerId/$createdAtas system properties, which pins the source to$createdAt(the only timestamp an immutable, create-once document carries). A bucketed index involves$createdAt, so the existing admission rule keeps it from being the proof index;requiredmembership makes delete-by-values reproduce the exact bucket set the create wrote.index_only_entry_paths_and_key) — level segments viaIndex::level_key, bucket value keys viaTimeRangeTransform::entry_keys_for_raw, the same derivation the walkers write with so probe and write paths cannot drift. The delete-side commitment probe requires ALL bucket entries to carry the row commitment (probe-all-buckets, fail-closed); the create-side duplicate probe fires on ANY existing entry.IN_TIME_RANGEcount aggregates work through the existing pickers unchanged.0-tree's stateless apply now also claims its real value-tree parent type instead ofNormalTree.beatdoctype (byHourHashtag[$createdAt, hashtag] → $ownerIdon a 3600s/900s grid — overlap factor 4 — with the count axes;byHashtagas the $createdAt-free proof index). E2e pins: one commitment entry per bucket at arithmetic-pinned starts (and none outside), resolvedIN_TIME_RANGEbucket counts with unproved/proved parity, the synthesis refusal, delete removing every bucket entry plus falsified-timestamp refusal on the commitment probe, estimation upper bounds, and duplicate/overlap semantics. ABCI: full lifecycle with executed create/delete proofs through the non-bucketed proof index and duplicate refusal.Note:
ranked*axes on timeRange indexes stay rejected — that is #3740's general rule ("ranked queries have no time-bucket semantics"), not an indexOnly restriction.How Has This Been Tested?
cargo test -p dpp --features validation index_only— 37 passed (3 new bucketed tests)cargo test -p drive --features server,verify,fixtures-and-mocks --lib index_only— 32 passed (6 new beat tests);query::— 582 passed; count query module — 56 passedcargo test -p drive-abci index_only— 10 passedcargo clippy -p dpp -p drive -p drive-abci --all-features --all-targets -- -D warningsclean;cargo check --workspace --all-featurescleanBreaking Changes
Consensus-breaking on the unreleased PV14 only: contracts declaring
timeRangeon indexOnly indexes were rejected and can now register; the estimation padding change alters dry-run (never applied) fees for indexOnly types. No released protocol version changes behavior.Checklist:
For repository code-owners and collaborators only
🤖 Generated with Claude Code