ci: fix env syntax in release workflow#664
Merged
Merged
Conversation
Collaborator
|
Please merge |
QuantumExplorer
added a commit
that referenced
this pull request
May 15, 2026
Targets grovedb PR #664 head (4e20c338) — the follow-up to PR #663 that relaxes the leaf-strict `SizedQuery::limit` rule for carrier ACOR queries. The new shape unblocks the `Q8`-with-outer-range case: brand > "brand_050" AND color > "color_00000500" group_by = [brand] limit = 20 → Entries([("brand_051", 499), …, ("brand_070", 499)]) Proof(35 122 bytes), median 1.07 ms The proof bytes scale linearly with `limit`: 20 outer matches × ~1 700 B per per-brand ACOR boundary walk ≈ 35 KB, matching the per-In slope established by Q8 vs G7. Drive-side wire-up extending the existing `RangeAggregateCarrierProof` mode: - `mode_detection`: lifts `range_count > 1` for the specific shape (CountMode::GroupByRange + prove + exactly two range clauses on distinct fields + no In). Routes to the existing `DocumentCountMode::RangeAggregateCarrierProof` arm. - `path_query::carrier_aggregate_count_path_query`: generalized to accept either an `In` clause (G7 shape) OR a range clause (G8 shape) at the carrier position. The terminator's range becomes the inner ACOR `QueryItem`. Builder now takes `limit: Option<u16>` and threads it to `SizedQuery::new`. - `execute_carrier_aggregate_count_with_proof`: accepts `limit`, passes through to the builder. - `Drive::execute_document_count_range_aggregate_carrier_proof`: accepts `limit`, plumbs through. - `drive_dispatcher`: extracts `request.limit`, validates against `max_query_limit` (same validate-don't-clamp policy as `RangeDistinctProof`), passes through. - `verify_carrier_aggregate_count_proof[_v0]`: accepts `limit`, rebuilds the same `PathQuery` byte-for-byte. - `index_picker::find_range_countable_index_for_where_clauses`: extended to accept the two-range case — finds an index whose first property carries one range (the outer carrier) and whose terminator carries the other (the inner ACOR). Single-range case is unchanged. - `drive_dispatcher::where_clauses_from_value`: catches the system- wide parser's `MultipleRangeClauses` error for count queries. Structural validation lives in `detect_mode`; the regular-query parser's "all ranges must be on same field" rule was rejecting the G8 shape upstream. Bench: - Matrix entry `[brand] / where=brand > floor AND color > floor (limit 20)` flipped from rejected to `Proof(35 122 bytes)`. - New `query_g8_brand_gt_color_gt_grouped_by_brand_limit_20` criterion bench — 10 samples × 5 060 iters, median 1.07 ms (~4× G7's 256 µs because the outer walk is 10× longer). - New `G8` case in `display_group_by_proofs`. - `probe_carrier_acor_range_outer` now uses `limit = 20` (was unbounded in the previous commit's feasibility probe). Proof shrinks from ~83 KB to 35 122 B. Chapter 30: - G8 row in the nav table (`O(L · (log B + log C'))`, 1 072 µs, 35 122 B, `Entries(20 groups, sum = 9 980)`). - New "G8 — Carrier outer Range + Range, Grouped By `brand`" section with the same template as G1..G7: path query, verified payload, schematic proof display + interactive visualizer link, conceptual flowchart, per-layer (Layer-5+) merk-tree diagram. - Complexity variables note extends `k` (|IN|) with `L` (the caller's `limit` for the Range-outer carrier shape). Tests + verification: - cargo test -p drive --lib drive_document_count_query → 45 passing - cargo test -p drive --lib verify → 240 passing - All previously documented proof sizes unchanged (Q1..Q8 / G3..G7 byte-identical to before) - G8 end-to-end via the dispatcher matches the standalone grovedb- level probe (35 122 B; root hash 0x62ee7348… matches chapter fixture) - mdBook builds clean The grovedb rev points at PR #664's open head (4e20c338); will be rebased to the merge commit once the PR lands. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
QuantumExplorer
added a commit
that referenced
this pull request
May 15, 2026
…db to PR #664 merge Bumps grovedb to the merged PR #664 commit (7a649386) and adopts the platform-wide hardcoded outer-walk cap for G8's range+ACOR carrier shape: brand > "brand_050" AND color > "color_00000500" group_by = [brand] prove = true # caller MUST NOT pass `limit` → Entries([("brand_051", 499), …, ("brand_075", 499)]) Proof(43 638 bytes), median 1.26 ms The hardcoded constant `CARRIER_AGGREGATE_OUTER_RANGE_LIMIT = 25` lives in `query/drive_document_count_query/mod.rs` alongside `MAX_LIMIT_AS_FAILSAFE`. The dispatcher rejects any caller-supplied `limit` on this shape — the cap is part of the per-shape structural contract, not a runtime knob. Two reasons: 1. **Prover/verifier byte-for-byte agreement.** `SizedQuery::limit` feeds the merk-root reconstruction; if the caller could pick the value, the verifier would need a side channel to know which one was used. Hardcoding keeps proof bytes deterministic across callers. 2. **Proof-size bounding.** Linear in the cap (~1 700 B per outer match). 25 keeps the worst case under 50 KB (Tier-2 in the visualizer's shareable-link guidance) while covering typical "top-N brands by outer range" queries. Callers wanting fewer results narrow the where-clause range; callers wanting more results call repeatedly with disjoint outer-range windows. For the In-outer (G7) shape, the dispatcher also rejects any caller-supplied `limit` now — the In array's length already bounds the result, and accepting a sub-|In| limit would silently change which In-branches appear in the proof. Drive: - New constant `CARRIER_AGGREGATE_OUTER_RANGE_LIMIT: u16 = 25` in `drive_document_count_query/mod.rs`. - Dispatcher: split the `RangeAggregateCarrierProof` arm into the In-outer case (`limit` must be `None`) and the Range-outer case (`limit` must be `None` from the caller, hardcoded to 25 internally). Rejects caller-supplied `limit` on both with a clear error message. Bench: - `query_g8_brand_gt_color_gt_grouped_by_brand_limit_20` → `query_g8_brand_gt_color_gt_grouped_by_brand` (caller passes `None` now; the cap is platform-set). - Matrix entry label drops "(limit 20)"; verdict updated to mention the platform-cap. - `display_group_by_proofs` G8 case: caller passes `None`. - `probe_carrier_acor_range_outer` switched from `limit = 20` to `limit = 25` to match the platform's hardcoded value (the probe calls grovedb directly, so it sets the SizedQuery limit itself). Empirical numbers from the new bench run (100 000-row warmed fixture): - Q8 (brand == X AND color > floor) : 71 µs / 2 656 B - G7 (k=2) (brand IN[2] AND color > floor) : 256 µs / 4 332 B - G8 (L=25) (brand > X AND color > floor, group_by [brand]): 1.26 ms / 43 638 B Per-outer-match slope of ~1 700 B and ~50 µs holds across all three rows. Chapter 30: - G8 nav-table row updated to the new numbers (25 entries, 43 638 B, 1 260 µs, sum = 12 475). - New "Why the limit is hardcoded" subsection with the two-reason rationale. - All G8 prose, flowchart, and per-layer diagram references to "20" / "brand_070" / "9 980" / "35 122 B" replaced with "25" / "brand_075" / "12 475" / "43 638 B". - New visualizer link for the 25-entry proof (encoded payload size ≈ 56 KB — Tier-2; works in modern browsers, may truncate in some link-preview surfaces). - Complexity-variables note now describes `L` as "platform-wide outer-walk cap" rather than "caller's limit". Tests: - cargo test -p drive --lib → 3 141 passing - All previously documented proof sizes unchanged for Q1..Q8 / G1..G7 - mdBook build clean Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
Incorrect syntax for env vars, causing error
Incorrect type. Expected "string".yaml-schema: GitHub WorkflowWhat was done?
Declare env variable correctly. See example in docs.
How Has This Been Tested?
Untested
Breaking Changes
None
Checklist:
For repository code-owners and collaborators only