chore: update webpack to version 5 in DPP by shumkov · Pull Request #4 · dashpay/platform

shumkov · 2021-11-03T14:51:19Z

Issue being fixed or feature implemented

Need to update webpack to version 5 before monorepository migration

What was done?

Webpack was updated to version 5
Webpack configs were updated

How Has This Been Tested?

With tests

Breaking Changes

No

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

For repository code-owners and collaborators only

I have assigned this pull request to a milestone

feat: cbor to contract struct

feat: Identity validation

- Delete fake tests in make_sure_core_is_synced_to_chain_lock/v0 that never called the production method (CRITICAL #1) - Delete fake tests in verify_chain_lock_through_core/v0 that only exercised mock wiring, never the production method (CRITICAL #2) - Add real tree verification in protocol_upgrade tests: v12 now checks shielded pool, notes, nullifiers, and anchors trees (MAJOR #3) - Fix get_contract_with_fetch_info_and_fee assertion to verify the contract is Some, not just Ok (MEDIUM #4) - Rename test_transition_from_version_10 and add actual verification of v11/v12 artifacts (LOW #5) - Replace bare .unwrap() with .expect() in choose_quorum tests (LOW #6) - Remove empty-input smoke test for store_address_balances (LOW #7) - Fix test_decode_state_transition_at_exact_max_size to assert the correct property (not rejected as oversized) rather than incorrectly assuming zeros cannot decode Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

…ition order - Reorder worked example property table to match actual schema positions - Fix pitfall #4 to say schema position order, not alphabetical/BTreeMap Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

@thepastaclaw

… drop lock before persister I/O Addresses three findings from the @thepastaclaw review on commit 757f035 (the FFI/Swift wiring + tx-bytes plumbing in d8de2c2 and 8e9b75d already addressed the fourth — "FFI not wired" — and already reach the iOS build through the new `on_get_core_tx_record_fn` callback). ## #2 — fast-fail regression in `upgrade_to_chain_lock_proof` Pre-PR, a missing in-memory record errored fast with `AssetLockProofWait("Transaction X not found in account Y")`. After the helper landed, the missing case fell through to `wait_for_chain_lock(...)` and burned the full chainlock timeout before returning `FinalityTimeout` — a regression for genuine "tx never tracked" cases (wallet-state mismatch, post-wipe race). Restored the fast-fail: when both the in-memory map and the persister miss, the function returns the same `AssetLockProofWait` error pre-PR callers expected. The "persister returned a non-chainlocked record" case still falls through to `wait_for_chain_lock` (correct — the tx exists, just hasn't chainlocked yet). ## #3 — silent error downgrade on transient persister failure `record_or_persister` previously logged backend errors at `debug` and surfaced them as `None`. That's correct for the poll loops (`wait_for_chain_lock`, `wait_for_proof`) where the next tick retries — but wrong for `resolve_status_from_info`, which is a one-shot recovery call: a transient backend error silently classified the lock as `AssetLockStatus::Broadcast` even when the underlying tx was actually chain-locked, forcing `resume_asset_lock` down the wasteful `Broadcast → wait_for_proof` path with no operator-visible signal. Split the helper: * `record_or_persister` now returns `Result<Option<TransactionRecord>, PersistenceError>`. Call sites choose their own policy. * `record_or_persister_or_log` is the new poll-loop variant — same `Option` return, but logs persister errors at `warn` (up from `debug`) before downgrading to `None`. A persistent failure is now visible in operator logs. * The two poll-loop sites (`wait_for_chain_lock`, `wait_for_proof`) switched to `_or_log`. * The two fast-fail sites (`validate_or_upgrade_proof`, `upgrade_to_chain_lock_proof`) propagate `Err` as `AssetLockProofWait("Persister lookup for tx X failed: …")`, distinct from the "neither lookup found it" message. * The one-shot recovery site (renamed `resolve_status_with_in_memory`, see #4 below) logs at `error` and degrades to `None`, preserving recovery's "always make some progress" semantics while making the failure visible. Tests updated for the new signature. Added a new test `record_or_persister_or_log_swallows_backend_errors_as_none` covering the poll-loop variant; renamed the old "swallows" test to `propagates_backend_errors` and asserts `Err`. 121/121 tests pass. ## #4 — wallet-manager lock held across persister I/O `recover_asset_lock_blocking` was acquiring `self.wallet_manager.blocking_write()` and then dispatching to `resolve_status_from_info`, which after the helper's persister fallback could perform synchronous SQLite/SwiftData/FFI I/O behind the write lock — serializing other writers on a single disk lookup. Restructured into three phases: 1. **Lock held**: claim the `tracked_asset_locks` slot, snapshot the in-memory record (only when no proof was provided), drop the lock. 2. **No lock held**: resolve status, including the persister fallback. The renamed `resolve_status_with_in_memory(snapshot, ...)` takes the pre-snapshotted record so this phase no longer touches the wallet manager. 3. **Lock held**: re-acquire to commit the `TrackedAssetLock` entry. A re-check of `tracked_asset_locks.contains_key` handles the case where another caller raced in during phase 2 (first writer wins). Net effect: the persister I/O now runs without serializing other wallet-manager writers. The lock-hold time drops from "in-memory lookup + persister round-trip" to two short in-memory operations. Verification: - `cargo fmt --all`: clean - `cargo test -p platform-wallet --lib`: 121/121 (was 120, +1 from the new `_or_log` test) - `bash packages/swift-sdk/build_ios.sh --target sim --profile dev`: BUILD SUCCEEDED end-to-end including SwiftExampleApp link Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Three real fixes from Codex review on PR #3435: - **In dedup**: `expand_paths_and_count` and `expand_split_prefix_paths` now serialize each `In` value to the canonical index key and dedupe before forking. Previously `age in [30, 30]` would visit and sum the same subtree twice; same shape on the split path. - **SDK count not capped at document limit**: `DocumentCountQuery` and `DocumentSplitCountQuery` `TryFrom<&Self>` for `DriveDocumentQuery` now force `limit = None`. The proof verifier counts documents in the verified proof, so any limit on the wrapped `DocumentQuery` would silently truncate the count — most visibly in the WASM SDK, where `parse_documents_query` defaults `DocumentQuery.limit` to 100. - **Server prove path bound**: both count handlers now cap the underlying `DriveDocumentQuery` at `u16::MAX` matching documents rather than `None`. Previously the server materialized and proved every matching document, making empty-where count requests an unbounded resource sink. Until count-tree proof verification is implemented, callers needing exact counts on larger result sets should use `prove=false` with a covering countable index. Codex finding #4 (unique countable index allegedly returning 0) was checked and is not a bug: `Element::count_value_or_default()` returns 1 for non-CountTree elements, so the Reference stored at key [0] under a unique countable index reads as 1 correctly. Added a regression test to lock that behavior in. Tests added: - `test_count_query_in_operator_dedupes_duplicate_values` - `test_count_query_unique_countable_index_returns_correct_count` Book chapter updated to note the prove-path cap and the SDK-side limit-clearing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

@query

Unit tests pin the filter / predicate / round-trip invariants; runtime composition (SwiftData @query reactivity, coordinator @published mutations, view re-renders, SPV event routing) needs manual testnet validation. Six scenarios cover the happy path, the 🔴 double-tap-during-in-flight guard, crash recovery from both pre-IS-lock (status 1) and post-IS-lock (status 2/3) states, the failed-retry flow, and the `.completed` retention window. Also documents which upstream PR #3549 issues are tangential to our UAT (#1 / #5: different code paths; #2: mitigated by the persister's proofBytes capture at the IS-lock arrival moment; #3 / #4: doc fixes only). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…0) uniformity, FFI limit decode Three independent review findings from thepastaclaw / coderabbitai addressed together because the proto contract change in #2 is the single source of truth for both server (#2) and client (#4). **#1: Unknown `Select` enum discriminant** classified as `QueryError::InvalidArgument` instead of `not_yet_implemented`. `Select::try_from(42)` is structurally malformed wire input — there's no future protocol value that would make `42` a valid `Select` behavior, so the future-capability error class (with its "valid request structure, callers can keep it unchanged when capability lands" contract from `not_yet_implemented`'s docstring) is the wrong class. New test `reject_unknown_select_enum_value_as_invalid_argument` pins the discriminator so a future refactor that re-collapses the two error classes for "consistency" fails loudly. **#2: `limit: Some(0)` uniformly invalid across SELECT modes.** Pre-fix, three legacy behaviors collided on the same wire value: - `SELECT DOCUMENTS` `unwrap_or(0)` and forwarded to v0, where `limit=0` is "use server default" (accept-as-default). - `SELECT COUNT, {Aggregate, GroupByIn}` rejected via `is_some()` with mode-specific message (reject-as-invalid). - `SELECT COUNT, {GroupByRange, GroupByCompound}` passed `Some(0)` to drive (accept-as-zero). Three semantics for the same wire bytes is bad contract. The v1 wire's whole point of switching to `optional uint32` was to make "unset" explicit (`None`), so `Some(0)` only makes sense as an *explicit* zero — structurally meaningless regardless of mode. Centralized `limit == Some(0)` rejection at the top of `validate_and_route`; the existing per-mode `is_some()` checks still catch `Some(N>0)` correctly. Updated the documents-path `unwrap_or(0)` comment to note `Some(0)` can't reach it. Proto docstring on `optional uint32 limit` calls out the cross-mode contract explicitly. New test `reject_limit_some_zero_uniformly_across_select_modes` exercises all 5 mode combinations and asserts the centralized message fires. **#4: FFI `dash_sdk_document_count` limit decode matches docs.** Pre-fix doc said `-1` = unset, `≥0` = explicit cap. Implementation mapped every negative value to `0` (SDK's unset sentinel), and `0` was also the SDK's unset sentinel — so `-1`, `-2`, `-100`, AND `0` all silently meant "use server default", masking caller bugs from uninitialized memory / arithmetic underflow / etc. Extracted the decode into `decode_ffi_limit(i64) -> Result<u32, _>` so it's unit-testable in isolation. New contract is single-valued per input: `-1` → unset sentinel; `> 0` → explicit cap; `0` and `< -1` → rejected at the FFI boundary with messages directing callers to valid alternatives. Server-side #2 rejection happens anyway, but surfacing the rejection at the FFI is faster and mode-independent. 5 new tests cover each sentinel category (minus_one_is_unset, zero_is_rejected, negative_other_than_minus_one_is_rejected, positive_decodes_verbatim, over_u32_max_is_rejected). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…r range) Lifts the `mode_detection.rs:140` rejection for the `GroupByIn + In + range + prove` case, now that grovedb PR #663 exposes `AggregateCountOnRange` as a carrier subquery under outer `Keys`. The new shape returns one `(in_key, u64)` per resolved In branch in a single proof: brand IN ["brand_000", "brand_001"] AND color > "color_00000500" group_by = [brand] → Entries([("brand_000", 499), ("brand_001", 499)]) Proof(4 332 bytes), median 255.9 µs Drive-side wire-up - New `DocumentCountMode::RangeAggregateCarrierProof` variant. - `mode_detection::detect_mode`: rejection lifted for `CountMode::GroupByIn` carrying `(In + range)`; routes to the new mode. Aggregate-mode `In + range + prove` still rejected (no group_by means caller asks for a single sum, which carrier-ACOR can't safely produce without verifier trust in the SDK's summation). - New `DriveDocumentCountQuery::carrier_aggregate_count_path_query` builder in `path_query.rs` — outer Keys per In value, subquery_path through the index's middle properties (`==` clauses) plus the terminator name, subquery is `Query::new_aggregate_count_on_range(range_item)`. Mirrors the In-fan-out pattern from `distinct_count_path_query` but with the carrier-ACOR subquery composition. - New executor `Drive::execute_document_count_range_aggregate_carrier_proof` in `executors/range_aggregate_carrier_proof.rs`, plus inner `DriveDocumentCountQuery::execute_carrier_aggregate_count_with_proof` in `execute_range_count.rs`. - New verifier `DriveDocumentCountQuery::verify_carrier_aggregate_count_proof` (`v0`) wrapping `GroveDb::verify_aggregate_count_query_per_key`. Returns `(RootHash, Vec<(Vec<u8>, u64)>)`. - Added the new method version to `DriveVerifyDocumentCountMethodVersions` (defaults to `0` in `v1.rs`). - Dispatcher arm in `drive_dispatcher.rs` matches the new mode and returns `DocumentCountResponse::Proof(...)`. Bench - Matrix entry `[brand] / where=brand IN[2] AND color > floor` flipped from rejected ("no — single-field GROUP BY with both `In` and range") to allowed ("yes (RangeAggregateCarrierProof — carrier ACOR per In branch)") with `prove: Proof(4 332 bytes)`. - New `query_g7_brand_in_color_gt_grouped_by_brand` criterion bench — 10 samples × 9 295 iters, median 255.87 µs (~4× Q8's 71 µs because it's two parallel Q8-shaped descents). - New `G7` case in `display_group_by_proofs` emits the full 186-line carrier-ACOR proof verbatim as `[gproof] G7 [brand] / where=...`. Chapter 30 (`book/src/drive/count-index-group-by-examples.md`) - G7 added to the navigation table (`O(k · (log B + log C'))`, 255.9 µs, 4 332 B, `Entries(2 groups, sum = 998)`). - New "G7 — Carrier `In` + Range, Grouped By `brand`" section with the same template as G1..G6: path query, verified payload, proof size, proof display (schematic + interactive visualizer link), narrative, conceptual flowchart, per-layer (Layer-5+) merk-tree diagram. - "Group-By Shapes That Are Not Allowed" section's bucket #4 removed (the "incoming" placeholder), replaced with a historical note pointing forward to G7. Tests + verification - `cargo test -p drive --lib drive_document_count_query` → 45 passing - `cargo test -p drive --lib verify` → 240 passing - All chapter 29 / chapter 30 documented proof sizes (Q1..Q8, G3..G6) unchanged — wire-up is purely additive on top of grovedb PR #663. - mdBook builds clean. Closes (in this PR): chapter 30 G7 placeholder. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Adds the SELECT AVG wire format end-to-end so callers can encode AVG queries today; execution returns NotYetImplemented in the same way SUM landed first as a wire-stable surface ahead of executor bodies. Both features unblock on the same grovedb PR 670 dependency (`AggregateCountAndSumOnRange` + PCPS element variant). Why no pre-computed average on the wire? The response carries the `(count, sum)` pair the underlying PCPS primitive yields in one root-hash-committed traversal, and the client divides. This preserves full precision and lets each caller pick its own representation — integer-truncated, floating-point, decimal. Pre-dividing on the server forces a choice that loses information for callers that wanted a different one. Changes: - proto: AverageEntry / AverageAggregate / AverageEntries / AverageResults messages + averages variant in ResultData (field #4). - rs-drive: drive_document_average_query module with DocumentAverageRequest/Response, AverageMode, AverageEntry types and a dispatcher stub returning NotYetImplemented. - rs-drive-abci: RoutingDecision::Average + dispatch_average_v1; SelectFunction::Avg now routes (was previously rejected at validation). - rs-drive-proof-verifier: DocumentAverage (count + sum) + helper `as_f64()`, DocumentSplitAverages + SplitAverageEntry + helper `into_flat_map() -> BTreeMap<key, (count, sum)>`. FromProof stubs return NotImplemented (same as DocumentSum / DocumentSplitSums). - rs-sdk: Fetch impls + MockResponse roundtrip for DocumentAverage / DocumentSplitAverages. - rs-sdk-ffi: dash_sdk_document_average extern "C" stub. - wasm-sdk: getDocumentsAverage + getDocumentsAverageWithProofInfo stubs returning typed not-implemented errors. drive 3165/3165, dpp 3461/3467 (6 ignored), drive-proof-verifier 225/225, drive-abci 2466/2475 (9 ignored), dash-sdk 117/123 (6 ignored). clippy --workspace --all-features -D warnings clean.

Addresses Codex findings #2 (partial), #3 (full), #5 (full): ## #3 Sum aggregation overflow (P1) — full fix The proof and no-proof paths used inconsistent overflow semantics that were both wrong for a deterministic protocol: - `execute_range_sum.rs:113` used `saturating_add` (silent clamp) - `execute_point_lookup.rs:48` used iterator `.sum::<i64>()` (panics in debug, wraps in release) Replaced both with `checked_add` + a typed `QuerySyntaxError::Unsupported` error so an overflowed aggregate fails deterministically with a clear user-facing message at the same point in both paths. ## #5 Stale gRPC clients (P2) — full fix `yarn build` in `packages/dapi-grpc/` regenerates the static clients for web, Node.js, Objective-C, and Python (Java is service-stub only). All five now include `SumResults`, `AverageResults`, `sums`, `averages`, `aggregate_sum`, `aggregate_average`, and the entry types. The Rust client uses `tonic_prost_build` at compile time so it was never stale. ## #2 U64 summable values (P1) — partial fix The deeper issue (DPP accepts U64 summable; values > i64::MAX would silently overflow grovedb's i64 sum aggregator) needs either schema- inference restructuring or a document-level validator — neither small enough for this PR. The symptom is mitigated here: `read_document_sum_contribution` now returns `DriveError::InvalidInput` (user-facing) instead of `CorruptedCodeExecution` (internal corruption signal) on i64 conversion failure, with the property name and the underlying conversion error interpolated into the message. A user submitting a document whose sum-bearing property value exceeds i64::MAX now gets a clean "value cannot be represented as i64" error rather than an internal corruption error. The DPP-level rejection of U64 is tagged as a TODO with the design context preserved. drive 3165/3165, dpp 3461/3467 (6 ignored). clippy --workspace --all-features -D warnings clean. ## Skipped (tracked follow-ups) - #1 cost estimation paths still use `Element::required_item_space` — needs grovedb's `required_item_with_sum_item_space` helper which doesn't exist upstream yet. - #4 mixed count/sum shared-prefix indexes — needs a failing repro test to demonstrate the path is reachable from valid contracts.

chore: update webpack to version 5 in DPP

beb0a94

shumkov added this to the v0.22.0 milestone Nov 3, 2021

shumkov merged commit b0dde36 into master Nov 3, 2021

shumkov deleted the dpp-webpack-5 branch November 3, 2021 14:52

shumkov pushed a commit that referenced this pull request Nov 23, 2022

Merge pull request #4 from dashevo/feat/contract-struct

ef98515

feat: cbor to contract struct

shumkov pushed a commit that referenced this pull request Nov 23, 2022

Merge pull request #4 from dashevo/identity_validation

10ab3d2

feat: Identity validation

thepastaclaw mentioned this pull request Mar 20, 2026

docs(book): add document serialization wire format chapter #3392

Merged

2 tasks

thepastaclaw mentioned this pull request May 6, 2026

feat(swift-sdk,platform-wallet): wire shielded send end-to-end (all 4 transitions) #3603

Open

5 tasks

QuantumExplorer mentioned this pull request May 7, 2026

fix(platform-wallet): fall back to persister for chainlocked asset-lock tx records #3619

Merged

QuantumExplorer mentioned this pull request May 11, 2026

feat(platform)!: verifiable, bounded count queries on a unified endpoint #3623

Merged

5 tasks

Claudius-Maginificent mentioned this pull request May 18, 2026

feat(platform-wallet): persistor backports — retry-safe flush, prepare_cached writers, functional load() #3643

Merged

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore: update webpack to version 5 in DPP#4

chore: update webpack to version 5 in DPP#4
shumkov merged 1 commit into
masterfrom
dpp-webpack-5

shumkov commented Nov 3, 2021

Labels

1 participant

Conversation