Repository navigation
feat(dpp)!: refersTo finds a document with findBy and checks it with where - #5197
Conversation
…where
A document reference now says how its document is found and what that
document must hold in two maps, both keyed by the referenced document's
property:
- findBy replaces lookup. It names the properties the document is found
by; the index is the unique index over exactly those properties, so a
contract no longer names it.
- where replaces propertyAgreement, which was keyed by the referring
property.
- listElement is folded into permanentDocument with inList, found by
findBy { "$id": <property> }.
The parser refuses lookup, propertyAgreement and the listElement type on
every parse. Meta-schema v3 and the parser are edited in place: protocol
version 14 is unreleased. The parsed declarations are unchanged apart
from the lookup's index name, which is now resolved from the referenced
type; ReferencedDocumentLookupInvalidError carries the findBy names.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important Review skippedToo many files! This PR contains 124 files, which is 24 over the limit of 100. To get a review, reduce the PR to 100 files or fewer by splitting it into smaller PRs or changing its base branch. Upgrade to a paid plan to raise the limit. This review couldn't start because sufficient usage credits or metered capacity aren't available. Add credits or update usage-based reviews in the billing tab, then retry. ⚙️ Run configurationConfiguration used: Repository: dashpay/platform/.coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (124)
You can disable this status message by setting the 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 |
|
📖 Book Preview built successfully. Download the preview from the workflow artifacts. Updated at 2026-09-29T12:35:29.128Z |
|
🔍 Review in progress — actively reviewing now (commit 8bb1ab3) · triage: critical |
|
Reviewed |
Basic explanation
A
refersTodocument reference could say three things in three differently shaped places:lookup(which unique index finds the document, named by index, plus how its key is built),propertyAgreement(what the found document must hold, keyed the other way round), and a separatelistElementreference type. A reader had to open the referenced type to learn whatlookup.indexcompared, and had to remember which map was keyed by which side.Now a reference says it in two maps, both keyed by the referenced document's property:
findBy: the properties the document is found by. The platform uses the unique index whose properties are exactly those; the contract no longer names the index.where: what the document found must also hold.A list reference is a
permanentDocumentwithinList, found byfindBy: { "$id": <property> }. WithoutfindBy, the value is the document's$id, as before.This only changes how contracts are written. The parsed declarations, and so validation, fees and execution, are the same. Protocol version 14 is unreleased, so meta-schema v3 and the parser are edited in place.
Before and after
Each example first shows the two document types, as this PR leaves them. They are trimmed to what the reference reads: other properties, and the references of properties the example does not read, are left out. Then the reference as it was written before.
1.
findBy: a moderator must hold a join request for the charterFrom the moderation charters system contract. An added moderator's
memberIdmust be the owner of ajoinRequestfor the same submitted charter.The document type referred to,
joinRequest:The referring document type,
addedModerator:findBynamessubmittedCharterIdand$ownerId, exactly the properties ofbySubmittedCharter, so that index finds the join request: itssubmittedCharterIdis the added moderator's, and its owner ismemberId(".").byOwnercovers$ownerIdalone and is not unique, so it could never be chosen.Before, the same
refersTonamed the index, and a reader had to openjoinRequestto learn what it compared:2.
where: a join request goes to the charter's leaderFrom the moderation charters system contract. A join request's
submittedCharterIdmust name a charter whose owner, the leader, is the request'srecipientId.The document type referred to,
submittedCharter:The referring document type,
joinRequest:There is no
findBy, sosubmittedCharterIdis the charter's$id.whereis keyed likefindBy, by the charter's property: the charter's$ownerIdmust equal this request'srecipientId.Before, the pair was keyed the other way round, by the referring property:
3.
inList: a removed moderator must be an elected memberFrom the moderation charters system contract. A removed moderator's
memberIdmust be one of themembersof the elected charter thatelectedCharterIdnames.The document type referred to,
electedCharter:The referring document type,
removedModerator:findByfinds the charter by its$id, read fromelectedCharterId, andmemberIdmust be in itsmembers.electedCharterIditself refers to the charter, whose owner, the leader, must be the writer.Before, the list reference was a type of its own, and the charter was found by a
$idpair:4. A
findByfunction: commit and revealFrom the commit-and-reveal test contract, whose
preorderanddomainhave the shape of DPNS's. A domain reveals the salt of a commitment made earlier.The document type referred to,
preorder:The referring document type,
domain:findByfinds the preorder whosesaltedDomainHashis the hash of the domain's salt, label and parent, throughsaltedHash, the unique index over that one property.wherethen asks that the preorder's owner is the domain's writer. The preorder must be at least one block old, and the create deletes it.Before, the index was named in
lookup, and the function sat inpropertyAgreementbeside a pair keyed the other way:What changed
refersTotakesfindByandwhereinstead oflookupandpropertyAgreement;inListneeds apermanentDocumentfound byfindBy { "$id": ... }; thelistElementtype is gone;agreementFunctionisfindByFunction. Descriptions rewritten.apply_property_reference0, in place): parsesfindByinto the existingDocumentReferenceLookupandwhereintoproperty_agreement(flipped back to the parsed model's referring-side key; a referring value may be compared once). It refuseslookup,propertyAgreementand thelistElementtype on every parse, naming what replaced each, so a contract written with them never loads with another meaning. On registration and update the meta-schema, which does not admit them, refuses them first (JsonSchemaError, naming only the unknown keyword).DocumentReferenceLookupno longer stores an index name.resolve_indexpicks the unique index over exactly the propertiesfindBynames (not bucketing its first property), used by the contract-level and registration checks and by the batch fetch guard. A type's indexes never change after registration, so the samefindByalways resolves to the same index. Errors list the type's unique indexes when none fits.ReferencedDocumentLookupInvalidError(40137): its second field carries the propertiesfindBynames instead of an index name (same position).documentTypeReferencesreportsfindBy,whereandinList; TypeScript types updated (DocumentReferenceFindBy,DocumentReferenceWhere,DocumentReferenceFindByFunction).inListshape.In-place changes to shipped generations
None. Every edit is to protocol version 14 (meta-schema v3, parser generation 3,
apply_property_reference0), which no public network runs yet. Testnet and mainnet are on protocol version 13; devnets on a 4.2 beta need a re-cut, since contracts stored there with the old keywords no longer load.Follow-ups
lookup,propertyAgreementorlistElementneed rewriting once this lands.Checklist
🤖 Generated with Claude Code
PR Hygiene ·
8bb1ab3/skip-botsproceeds without the ones not yet reported/self-reviewedonce the bots are donejs-wasm-sdk(packages/js-evo-sdk/README.md) — shumkovdpp— you own itrs-drive-abci— you own itrs-drive— you own itWhen every box is checked the
PR Hygienecheck passes and this can merge.