Skip to content

feat(platform)!: refersTo on typed array elements (PV14) - #4928

Merged
QuantumExplorer merged 2 commits into
v4.2-devfrom
feat/typed-array-element-refers-to
Sep 23, 2026
Merged

QuantumExplorer merged 2 commits into
v4.2-devfrom
feat/typed-array-element-refers-to

Conversation

@QuantumExplorer

@QuantumExplorer QuantumExplorer commented Sep 23, 2026 •

Copy link
Copy Markdown
Member

Issue being fixed or feature implemented

Typed scalar arrays (#4922, #4923, #4924) refused refersTo on their elements; #4922 left a note that a per-element reference would later be read from the same items map and folded into the identifier element. The moderation charters contract (#4898) needs it: submittedCharter.reasons is a list of references to reason documents, and electedCharter.members is a list of references too (it also needs the separate index-resolved lookup, which is not part of this PR; only the reasons shape has to work here). This PR adds refersTo on identifier elements at protocol version 14.

What was done?

An identifier element may carry refersTo

Meta-schema v3 $defs/documentArrayItem gains refersTo, reusing the property definition by $ref (#/$defs/documentSchema/properties/refersTo) with identityPublicKey excluded, and a dependentSchemas rule admitting it on identifier elements only. parse_typed_array 0 (unreleased, extended in place) folds it into the element through the same versioned apply_property_reference a scalar identifier goes through, so the two paths cannot drift.

"reasons": {
  "type": "array", "minItems": 0, "maxItems": 64, "uniqueItems": true,
  "items": {
    "type": "array", "byteArray": true, "minItems": 32, "maxItems": 32,
    "contentMediaType": "application/x.dash.dpp.identifier",
    "refersTo": { "type": "permanentDocument", "documentType": "reason" }
  },
  "position": 2
}

Before: JsonSchemaError at /properties/reasons/items (validating parse), refersTo is not supported on the elements of a typed array (stored parse).

After:

DocumentPropertyType::TypedArray(TypedArrayProperty {
    item_type: Box::new(DocumentPropertyType::IdentifierWithReference(
        DocumentPropertyReferenceTarget::PermanentDocument {
            contract_id: None,
            document_type_name: "reason".into(),
            property_agreement: BTreeMap::new(),
        },
    )),
    min_items: Some(0), max_items: 64, unique_items: true, ..
})

Every target a scalar takes works on an element with the same keys (identity, contract with contractRequirements, token, permanentDocument and deletableDocument with contractId, documentType, propertyAgreement). Refused:

declaration validating parse stored parse
items.refersTo: { "type": "identityPublicKey", "keyIdProperty": "keyId" }, or #4916's identityProperty form JsonSchemaError at .../reasons/items/refersTo identityPublicKey refersTo is not allowed on the elements of a typed array: it pairs one key id with the reference, which cannot pair with many elements
refersTo on an integer, string or plain byte array element JsonSchemaError at .../reasons/items/... refersTo is only allowed on identifier elements of a typed array
refersTo on the array itself JsonSchemaError refersTo on a typed array belongs on its items, where it applies to every element (was: refersTo is only allowed on identifier properties); for identityPublicKey, ... not allowed on a typed array or on its elements

DocumentPropertyType::reference() is new and returns PropertyReference::Value(target) for a scalar, PropertyReference::Elements { target, max_items } for a typed array and PropertyReference::KeyId(&KeyIdReference) for #4916's key reference on a key id; both validators, the per-document bound and wasm-dpp2 enumerate references through it. The element checks live in apply_element_reference, versioned on the same apply_property_reference slot, so a table with None ignores the keyword on elements as it does on properties. There is no DocumentPropertyType::as_document_reference (it lives on the target); the callers that only take scalar references now say why in a comment: index preallocation (a typed array is never an index property), the chained and composite query joins (not indexable, a join value is one identifier), the boundTo check from #4918 (elements cannot be identityPublicKey), and deletable_document_reference_target_is_gone (see the immutable rule below).

Every element is checked at document create and replace

validate_document_type_references_v0 gains the TypedArray arm. The per-reference check is extracted into validate_reference_v0, which takes the referenced id and the path its errors name; the scalar arm calls it exactly as the loop body ran before. Each element is checked in list order and the first that fails refuses the write with the error a single reference gives, its path the element's list path (#4924's list[i], zero-based; - is no longer allowed in names). No new error type.

Before (contract refused, so no such document could exist). After, a submittedCharter whose third reason is missing:

ReferencedEntityNotFoundError (40120)
referenced permanent document (own contract, document type reason) 7xQ...Zp not found for path reasons[2]

A writer gate on the elements (propertyAgreement: { "$ownerId": "$ownerId" }), written by an identity that owns the first reason but not the second:

ReferencedDocumentPropertyMismatchError (40127)
the document's $ownerId does not agree with the referenced document's $ownerId (propertyAgreement on reasons[1])

The referring side of an agreement is a property of the referring document (or its $ownerId), the same for every element; the referenced side is that element's referenced document's property. An empty or absent list checks nothing. A missing referenced document type (40121), deletability (40122, 40131), contract requirements (40135) and the rest come out the same way.

Replace rules

The single-reference rules apply element by element. A changed list re-validates the elements the stored list did not hold: the replace action now carries the stored value of each changed property (stored_changed_values), and the elements it held are unchanged references, left alone as an unchanged single reference is. Every element is re-validated when a property bound by a propertyAgreement changed, on every replace for an agreement keyed by $ownerId, and on every replace for deletableDocument elements. An element repeating an earlier one of the same list is not fetched again.

topicCharter { reasons: [r1], topic: "dash" }         # r1.topic is then changed to "btc"
replace { reasons: [r1, r2], topic: "dash" }          -> ok: only r2 is checked
replace { reasons: [missing, r1, r2], topic: "dash" } -> ReferencedEntityNotFoundError, path reasons[0]
replace { reasons: [r1, r2], topic: "btc" }           -> the bound topic changed: every element is checked

draftList { drafts: [d1, d2], body: "second" }        # d2 is then deleted
replace  { drafts: [d1, d2], body: "third" }          -> ReferencedEntityNotFoundError, path drafts[1]
replace  { drafts: [d1],     body: "third" }          -> ok

Fees and the per-document bound

Every read is billed as a single reference's. A foreign contract holding the referenced document type is fetched (and billed) once per list, not once per element; a scalar reference keeps its one fetch. Processing fee of creating a submittedCharter over the same list in a plainCharter (same shape, no refersTo), on identical fresh platforms:

elements 0 1 2 4
surcharge (credits) 49,360 68,980 81,620 118,140

(The 49,360 at zero elements is the two document types' own path difference.)

The worst case needed its own bound. maxItems is capped at max_typed_array_items (1024) per array, but a document type may declare up to 100 top-level properties, so a type of 100 referencing arrays could ask for 102,400 reads per document write. Today the 20 KiB max_state_transition_size happens to cap a transition at roughly 600 identifiers, but that limit is tied to Tenderdash's max-tx-bytes and says nothing about reads. New SystemLimits::max_references_per_document (256 in SYSTEM_LIMITS_V4, backfilled into V1 to V3 and the mock table, read only by parser generation 3): registration counts one per property with a reference (an identifier with refersTo, or a key id carrying #4916's key reference, each one read) and maxItems per typed array of referencing elements, under full validation only (a stored contract is read as it is).

reasons: maxItems 255, plus ref1, ref2 scalar references
-> document type "submittedCharter" declares references for up to 257 values per document (one per property with refersTo, maxItems per typed array of referencing elements), above the maximum of 256

The charters need 64 (reasons) and 15 (members).

An immutable property may not hold a deletableDocument reference no replace could clear

Every replace re-validates deletableDocument references, so once a target is deleted the property must change, which an immutable property cannot: the document could never be replaced again. The one way out, a replace removing a single reference once its target is gone, reads the one identifier the removed top-level property held (removed_identifier_fields), which neither a list nor an object provides. Registration now refuses a typed array of them (top level or inside an immutable object) and a single one inside an immutable object; a single one that is itself the immutable top-level property keeps its way out, and permanentDocument references may be immutable.

"immutable": ["drafts"], drafts.items.refersTo: { "type": "deletableDocument", ... }
-> document type "..." lists "drafts" as immutable, but "drafts" is a typed array of deletableDocument references: every replace re-validates it, ...
"immutable": ["team"], team.lead.refersTo: { "type": "deletableDocument", ... }
-> ... but "team.lead" is a deletableDocument reference inside an object: ...

This is a design call I made; the alternative is to extend the replace carve-out to "the new list is the stored list with only dead elements removed", which needs the replace action to carry the stored list. Easy to relax later if that is preferred.

Registration checks visit element references

data_contract_reference_validation 0 checks an element declaration once, as a single one; its errors name it documentType.path[]:

ReferencedDocumentPropertyAgreementInvalidError (40126)
invalid propertyAgreement pair subject -> topic declared at topicCharter.reasons[]: the declaring document type does not define the referring property

Contract updates

A changed element refersTo (added, removed, a new type, documentType or propertyAgreement) is an incompatible schema change, like a scalar's: IncompatibleDocumentTypeSchemaError at /properties/reasons/items/refersTo.... The compatibility rules already covered it (items descends one level into the refersTo rule); this PR pins it with a test.

Clients

  • wasm-dpp2: a typed array's identifier item reports refersTo?: DocumentPropertyReferenceTarget, and documentTypeReferences lists element references at their list path; the js-evo-sdk README now says so.

    contract.documentTypeTypedArrays('submittedCharter')[0].items
    // before: { type: 'identifier' }
    // after:  { type: 'identifier', refersTo: { type: 'permanentDocument', contractId, documentType: 'reason' } }
    contract.documentTypeReferences('submittedCharter').map((r) => r.path)
    // before: []   after: ['reasons[]']
  • Swift and Kotlin: the brief said fix(dpp)!: typed array review fixes: hyphenated list paths, element constraints, untrusted lists, Swift refusal #4924 made Swift refuse typed arrays and to leave that. feat(sdk): typed arrays in the Swift SDK and both mobile example apps (PV14) #4926 merged while this was in flight and replaced the refusal with typed array support in the Swift SDK and both example apps. Neither models reference declarations (scalar or element), so an element carrying refersTo reads there as a plain identifier element and consensus does the checking. Nothing changed on mobile.

Docs

Book: a "References on the Elements" subsection under typed arrays in book/src/data-model/documents.md. Changelog: item 31 in v14.rs, after #4918's 29 and #4916's 30; also finished item 26's cut-off last sentence.

In-place changes to shipped generations

  • document_reference_validation 0 (drive-abci): every validation table selects it, but its only callers are document create state validation 2 and replace state validation 1, which only protocol version 14 selects. The scalar path is output-identical (same reads in the same order, same bills: the per-property contract map holds at most the one fetch it makes), and the element arm acts on a TypedArray property, which cannot exist before protocol version 14 (parse_typed_array is None in CONTRACT_VERSIONS_V1 to V5).
  • data_contract_reference_validation 0 (drive-abci): every table selects it, its only callers are data contract create and update state validation 1 (protocol version 14). The scalar path is unchanged; the element arm is unreachable earlier for the same reason.
  • create_document_types_from_document_schemas 1 (dpp): a comment only.
  • The document replace action transformer (unversioned, every protocol version) also records stored_changed_values, the stored value of each changed property. Only the reference validation reads it, reached from replace state validation 1 (protocol version 14); the action is in memory only, and no other outcome or fee changes.
  • SYSTEM_LIMITS_V1 to V3 gain max_references_per_document, read only by parser generation 3 (protocol version 14).

parse_typed_array 0, apply_property_reference 0 and meta-schema v3 are selected by protocol version 14 only, which is unreleased.

How Has This Been Tested?

New tests:

  • dpp try_from_schema/v3/typed_array_reference_tests.rs: should_parse_an_element_reference_of_each_target_type (both parse paths), should_refuse_an_identity_public_key_reference_on_an_element, should_refuse_refers_to_on_a_non_identifier_element, should_refuse_refers_to_on_the_typed_array_itself, should_refuse_an_element_property_agreement_naming_an_unusable_system_property, should_refuse_an_element_reference_before_protocol_version_14_and_accept_it_at_14, should_bound_the_references_one_document_can_carry, should_refuse_an_immutable_typed_array_of_deletable_document_references, should_round_trip_a_contract_with_an_element_reference_through_platform_serialization.
  • dpp validate_update: should_refuse_a_contract_update_that_changes_an_element_refers_to.
  • drive-abci registration (data_contract_create): should_register_contract_with_typed_array_element_references, should_reject_an_element_agreement_on_a_missing_referring_property, should_reject_an_element_agreement_on_a_missing_referenced_property. The "missing referring or referenced property" checks need the referenced contract and live at registration in drive-abci, so those tests are there rather than in dpp.
  • drive-abci write time (batch/tests/document/typed_array_references.rs, fixture reference-validation-contract-typed-array-elements.json): every element existing succeeds, the third missing is refused with 40120 naming reasons[2], an empty list succeeds, a $ownerId element gate refuses a writer not owning a referenced reason (40127, reasons[1]), an element agreement holds against every referenced document and is re-checked when the bound property alone changes, a replace adding a missing element is refused, an unrelated replace while a deletableDocument element is dead is refused (and dropping it repairs the list), fees grow with the element count.
  • drive-abci, after review: a replace adding an element leaves the stored ones alone (a reason whose agreed topic drifted does not block it), a list nested in an object is named team.members[1] and re-validated when the object changes, contractRequirements on every element (40135, contracts[1]), a foreign contract fetched once per list, a repeated element fetched once (both fee tests fail when the memo or the repeat skip is removed).
  • wasm-dpp2 DocumentTypedArrays.spec.ts: the element reference on the items, in documentTypeReferences, and the identityPublicKey refusal (matched on its message).

Run locally after rebasing onto v4.2-dev 4527e5f (over #4918, #4926, #4916 and #4927):

  • cargo test -p dpp --lib -- data_contract::document_type data_contract::methods validation::meta_validators data_contract::serialized_version: 1342 passed
  • cargo test -p drive --lib state_transition_action: 1157 passed
  • cargo test -p drive-abci --lib -- batch::tests::document data_contract_create data_contract_update: 509 passed (includes feat(platform)!: key references on the writer's own identity (PV14) #4916's and feat(platform)!: keyRequirements on identity key references (PV14) #4918's reference tests)
  • cargo test -p platform-version: passed
  • cargo clippy -p dpp -p drive -p drive-abci --all-features --all-targets -- -D warnings: clean
  • cargo check -p wasm-dpp2 --target wasm32-unknown-unknown: clean
  • yarn workspace @dashevo/wasm-dpp2 build, then mocha DocumentTypedArrays.spec.ts and DocumentPropertyReference.spec.ts: 26 passing
  • cargo fmt --all

Not run locally: the full drive-abci suite and the wasm-dpp (v1) JS specs (this PR adds none there and changes no contract wire format).

Breaking Changes

Consensus, protocol version 14 only (unreleased): meta-schema v3 admits refersTo on identifier elements, document create and replace check every element, contract registration refuses a document type whose references exceed max_references_per_document and an immutable typed array of deletableDocument references. SystemLimits gains a field. wasm-dpp2: documentTypeReferences now also lists element declarations, whose path ends in [].

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 added "!" to the title and described breaking changes in the corresponding section if my code contains any
  • I have made corresponding changes to the documentation if needed
  • If I added or changed GroveDB structure, I described it in the area's structure.rs, regenerated grovedb-structure.json, and checked the structure viewer link posted on this pull request

For repository code-owners and collaborators only

  • I have assigned this pull request to a milestone

🤖 Generated with Claude Code

PR Hygiene · 89033c8

  • Bots — coderabbitai not yet · thepastaclaw not yet — /skip-bots proceeds without the ones not yet reported
  • Self-review — post /self-reviewed once the bots are done
  • Within your 5 open PRs — this one is beyond the limit; it waits until one merges
  • Build green
  • Approvals
    • files with no dedicated owner — you own it
    • js-wasm-sdk (packages/js-evo-sdk/README.md) — shumkov
    • dpp — you own it
    • rs-drive-abci — you own it
    • rs-drive — you own it

When every box is checked the PR Hygiene check passes and this can merge.

An identifier element of a typed array may carry a refersTo on its items,
which every element declares. The element parses to
IdentifierWithReference(target) inside item_type through the same
apply_property_reference a scalar identifier goes through; identityPublicKey
is refused on an element. Registration checks the declaration as a single
one, and document create and replace check every element as a single
reference, refusing the first that fails with that reference's error named
by the element's list path (reasons[2]).

Registration caps the references one document can carry at
SystemLimits::max_references_per_document (256) and refuses an immutable
typed array of deletableDocument references.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository: dashpay/platform/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 52adfe00-0b9d-4984-b0a9-01768681f84d

📥 Commits

Reviewing files that changed from the base of the PR and between 4527e5f and 7259762.

📒 Files selected for processing (34)
  • book/src/data-model/documents.md
  • packages/rs-dpp/schema/meta_schemas/document/v3/document-meta.json
  • packages/rs-dpp/src/data_contract/document_type/class_methods/create_document_types_from_document_schemas/v1/mod.rs
  • packages/rs-dpp/src/data_contract/document_type/class_methods/parse_typed_array/mod.rs
  • packages/rs-dpp/src/data_contract/document_type/class_methods/parse_typed_array/v0/mod.rs
  • packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/mod.rs
  • packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v3/mod.rs
  • packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v3/typed_array_reference_tests.rs
  • packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v3/typed_array_tests.rs
  • packages/rs-dpp/src/data_contract/document_type/index/preallocation.rs
  • packages/rs-dpp/src/data_contract/document_type/methods/validate_update/common/mod.rs
  • packages/rs-dpp/src/data_contract/document_type/property/mod.rs
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_reference_validation/mod.rs
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/action_validation/document/document_reference_validation/v0/mod.rs
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/mod.rs
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/typed_array_references.rs
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_common/data_contract_reference_validation/v0/mod.rs
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/mod.rs
  • packages/rs-drive-abci/tests/supporting_files/contract/reference-validation/reference-validation-contract-typed-array-elements-agreement-missing-referenced.json
  • packages/rs-drive-abci/tests/supporting_files/contract/reference-validation/reference-validation-contract-typed-array-elements-agreement-missing-referring.json
  • packages/rs-drive-abci/tests/supporting_files/contract/reference-validation/reference-validation-contract-typed-array-elements.json
  • packages/rs-drive/src/query/chained_document_query/mod.rs
  • packages/rs-drive/src/query/composite_document_query/mod.rs
  • packages/rs-platform-version/src/version/mocks/v2_test.rs
  • packages/rs-platform-version/src/version/system_limits/mod.rs
  • packages/rs-platform-version/src/version/system_limits/v1.rs
  • packages/rs-platform-version/src/version/system_limits/v2.rs
  • packages/rs-platform-version/src/version/system_limits/v3.rs
  • packages/rs-platform-version/src/version/system_limits/v4.rs
  • packages/rs-platform-version/src/version/v14.rs
  • packages/wasm-dpp2/src/data_contract/document_type_reference.rs
  • packages/wasm-dpp2/src/data_contract/document_type_typed_arrays.rs
  • packages/wasm-dpp2/src/data_contract/model.rs
  • packages/wasm-dpp2/tests/unit/DocumentTypedArrays.spec.ts
💤 Files with no reviewable changes (1)
  • packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/v3/typed_array_tests.rs

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.


📝 Walkthrough

Walkthrough

Typed-array identifier elements can now declare references. DPP parses and exposes these declarations, registration enforces reference limits, Drive validates elements during writes and replacements, and WASM bindings serialize the metadata.

Changes

Typed-array reference support

Layer / File(s) Summary
Schema parsing and reference contracts
book/src/data-model/documents.md, packages/rs-dpp/schema/..., packages/rs-dpp/src/data_contract/document_type/..., packages/rs-platform-version/...
Identifier elements may carry supported refersTo declarations. The parser stores them as IdentifierWithReference, while direct array declarations and identityPublicKey element references remain rejected.
Registration and schema-update validation
packages/rs-dpp/src/data_contract/document_type/class_methods/try_from_schema/..., packages/rs-dpp/src/data_contract/document_type/methods/validate_update/...
Full validation counts element references, rejects immutable arrays of deletableDocument references, and rejects changes to element reference declarations.
Document reference validation
packages/rs-drive-abci/src/execution/validation/..., packages/rs-drive-abci/tests/supporting_files/...
Document writes validate array elements in order, report indexed paths, reuse contract fetches, revalidate affected arrays, and apply reference billing and limits.
WASM bindings and query metadata
packages/wasm-dpp2/..., packages/rs-drive/src/query/..., packages/rs-dpp/src/data_contract/document_type/index/...
WASM APIs expose element references and path[] metadata. Typed reference arrays remain unavailable as scalar index or join properties.

Priority: ➖ Normal

Estimated code review effort: 4 (Complex) | ~60 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant ContractSchema
  participant DocumentTypeParser
  participant DocumentWriter
  participant PlatformState
  ContractSchema->>DocumentTypeParser: Parse items.refersTo
  DocumentTypeParser-->>ContractSchema: Store PropertyReference::Elements
  DocumentWriter->>PlatformState: Validate each array element reference
  PlatformState-->>DocumentWriter: Return referenced state and validation errors
Loading

Suggested reviewers: shumkov

Merge Risk: ⚪ Minimal · up to 72597

This change lets identifier elements in typed arrays declare references for the unreleased protocol version 14. It adds limits and per-element validation on document writes. Review found no concrete defect. Documents that leave out an optional reference array are still accepted, and the change is ready to merge.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 79.52% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 83 functions across 28 files. (5 skipped:… Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
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.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely identifies the main change: adding refersTo support to typed-array elements for protocol version 14.
Full details: Docstring Coverage

Explanation

Docstring coverage is 79.52% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 83 functions across 28 files. (5 skipped: 5 unsupported.)

  • Fix all pre-merge checks with AI
✨ Finishing Touches 💡 2
📝 Generate docstrings 💡
  • Commit to this branch
  • Create a new PR
🛠️ Fix failing CI checks 💡
  • Commit to this branch
  • Create a new PR
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR

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

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added this to the v4.2.0 milestone Sep 23, 2026
@github-actions

github-actions Bot commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

📖 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-09-23T01:21:50.517Z

@thepastaclaw

thepastaclaw commented Sep 23, 2026 •

Copy link
Copy Markdown
Collaborator

🕓 Review not started yet because the new head is waiting for the 30-minute push debounce.

  • Request normal review — click when the PR is ready for review.
  • Request priority review — click to move this review to the front of the queue.

Commit 89033c8. Normal review starts when eligible; priority review starts as soon as a slot is available.

@github-actions github-actions Bot added the waiting-bots Waiting for the review bots to report on this head label Sep 23, 2026

@QuantumExplorer QuantumExplorer left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed

…eplace (PV14)

Code review fixes for refersTo on typed array elements:
- a replace re-validates only the elements of a changed list the stored
  list did not hold (the replace action carries stored_changed_values),
  unless a bound property changed, a writer gate applies or the target is
  deletable; a repeated element is fetched once
- registration also refuses a single deletableDocument reference inside an
  immutable object, which no replace could clear
- PropertyReference gains KeyId and carries max_items on Elements, so the
  validators, the reference bound and wasm-dpp2 enumerate through one match
- the element checks move into apply_element_reference, versioned with
  apply_property_reference; an array-level identityPublicKey refersTo gets
  its own error
- shared test harnesses, new tests (nested list path, contract
  requirements, one foreign fetch per list, repeated elements, key id
  references in the bound), js-evo-sdk README

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@QuantumExplorer QuantumExplorer left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

waiting-bots Waiting for the review bots to report on this head

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants