[DRAFT] [DONT MERGE] feat: add rwa consent to metadata #747
Conversation
WalkthroughThis PR introduces support for app data schema version 1.11.0 and adds a new user consents metadata schema (v0.1.0). It includes updated type definitions, new JSON schema files, and modifications to the compilation script to handle the new userConsents metadata type. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Areas requiring attention:
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
📦 GitHub Packages PublishedLast updated: Dec 12, 2025, 08:37:18 PM UTC The following packages have been published to GitHub Packages with pre-release version
InstallationThese packages require authentication to install from GitHub Packages. First, create a # Create .npmrc file in your project root
echo "@cowprotocol:registry=https://npm.pkg.github.com" > .npmrc
echo "//npm.pkg.github.com/:_authToken=YOUR_GITHUB_TOKEN" >> .npmrcTo get your GitHub token:
Then install any of the packages above, either by exact version (i.e. # Yarn
yarn add npm:@cowprotocol/cow-sdk@pr-747
# pnpm
pnpm install npm:@cowprotocol/cow-sdk@pr-747
# NPM
npm install npm:@cowprotocol/cow-sdk@pr-747Update to the latest version (only if you used the tag)Every commit will publish a new package. To upgrade to the latest version, run: # Yarn
yarn upgrade @cowprotocol/cow-sdk
# pnpm
pnpm update @cowprotocol/cow-sdk
# NPM
npm update @cowprotocol/cow-sdkView PackagesYou can view the published packages at: https://github.com/cowprotocol/cow-sdk/packages |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/app-data/src/scripts/compile.ts (1)
108-133: Avoid silently collapsing rejected metadata lookups into''without identifying which doc failed.
Promise.allSettled(...).map(...)loses the rejection reason and the doc name, which makes failures hard to debug (esp. when adding new metadata docs likeuserConsents). Consider iterating results with the corresponding doc name and logging rejected reasons.- const metadataResults = await Promise.allSettled([ - getLatestMetadataDocVersion('quote'), - getLatestMetadataDocVersion('referrer'), - getLatestMetadataDocVersion('orderClass'), - getLatestMetadataDocVersion('utm'), - getLatestMetadataDocVersion('hooks'), - getLatestMetadataDocVersion('signer'), - getLatestMetadataDocVersion('widget'), - getLatestMetadataDocVersion('partnerFee'), - getLatestMetadataDocVersion('replacedOrder'), - getLatestMetadataDocVersion('userConsents'), - ]) + const metadataDocNames = [ + 'quote', + 'referrer', + 'orderClass', + 'utm', + 'hooks', + 'signer', + 'widget', + 'partnerFee', + 'replacedOrder', + 'userConsents', + ] as const + + const metadataResults = await Promise.allSettled( + metadataDocNames.map((name) => getLatestMetadataDocVersion(name)), + ) - const [ - latestQuoteVersion, - latestReferrerVersion, - latestOrderClassVersion, - latestUtmVersion, - latestHooksVersion, - latestSignerVersion, - latestWidgetVersion, - latestPartnerFeeVersion, - latestReplacedOrderVersion, - latestUserConsentsVersion, - ] = metadataResults.map((result) => (result.status === 'fulfilled' ? result.value : '')) + const resolved = metadataResults.map((result, i) => { + if (result.status === 'rejected') { + console.warn(`Failed to resolve latest metadata version for ${metadataDocNames[i]}:`, result.reason) + return '' + } + return result.value + }) + const [ + latestQuoteVersion, + latestReferrerVersion, + latestOrderClassVersion, + latestUtmVersion, + latestHooksVersion, + latestSignerVersion, + latestWidgetVersion, + latestPartnerFeeVersion, + latestReplacedOrderVersion, + latestUserConsentsVersion, + ] = resolvedpackages/app-data/src/generatedTypes/v1.11.0.ts (1)
93-126: GeneratedPartnerFeetype is quite complex—consider simplifying the underlying schema if possible.
This isn’t actionable in this generated file, but if consumers struggle with this union, schema tweaks (or explicit named definitions) can materially improve the emitted TS surface.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
packages/app-data/src/generatedTypes/index.ts(4 hunks)packages/app-data/src/generatedTypes/latest.ts(1 hunks)packages/app-data/src/generatedTypes/v1.11.0.ts(1 hunks)packages/app-data/src/schemas/userConsents/v0.1.0.json(1 hunks)packages/app-data/src/schemas/v1.11.0.json(1 hunks)packages/app-data/src/scripts/compile.ts(4 hunks)
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: jeffersonBastos
Repo: cowprotocol/cow-sdk PR: 327
File: packages/app-data/src/schemas/v0.3.0.json:1-10
Timestamp: 2025-06-10T03:06:46.146Z
Learning: Schema versions v0.1.0 through v0.7.0 in the app-data package are intentionally designed to allow additional properties (no "additionalProperties": false constraint), while versions v0.8.0 and later enforce strict validation. This represents a deliberate design evolution and historical schema versions should not be modified to add stricter validation.
Learnt from: jeffersonBastos
Repo: cowprotocol/cow-sdk PR: 327
File: packages/app-data/src/schemas/v1.1.0.json:10-14
Timestamp: 2025-06-10T02:39:24.134Z
Learning: In the CoW Protocol app-data schemas, v1.0.0.json and v1.1.0.json both intentionally use default version "0.11.0" rather than matching their filenames. This is a deliberate versioning design, not an error.
Learnt from: jeffersonBastos
Repo: cowprotocol/cow-sdk PR: 327
File: packages/app-data/src/schemas/hooks/v0.2.0.json:14-14
Timestamp: 2025-06-10T03:06:45.755Z
Learning: In the CoW Protocol app-data schemas, there are two different version concepts: the schema version (indicated by the filename like v0.2.0.json) represents the schema structure/capability version, while the default version field represents the content/data version for backward compatibility. When new schema versions add optional fields, the default version can remain the same to ensure existing implementations don't break.
📚 Learning: 2025-06-10T02:39:24.134Z
Learnt from: jeffersonBastos
Repo: cowprotocol/cow-sdk PR: 327
File: packages/app-data/src/schemas/v1.1.0.json:10-14
Timestamp: 2025-06-10T02:39:24.134Z
Learning: In the CoW Protocol app-data schemas, v1.0.0.json and v1.1.0.json both intentionally use default version "0.11.0" rather than matching their filenames. This is a deliberate versioning design, not an error.
Applied to files:
packages/app-data/src/generatedTypes/latest.tspackages/app-data/src/schemas/v1.11.0.jsonpackages/app-data/src/generatedTypes/index.ts
📚 Learning: 2025-06-10T03:06:53.585Z
Learnt from: jeffersonBastos
Repo: cowprotocol/cow-sdk PR: 327
File: packages/app-data/src/schemas/v0.2.0.json:34-39
Timestamp: 2025-06-10T03:06:53.585Z
Learning: In the CoW Protocol app-data schemas, nested schema references are intentionally kept at stable versions (like v0.1.0) even when the root schema version increases, to maintain backward compatibility when the referenced schemas have breaking changes.
Applied to files:
packages/app-data/src/generatedTypes/latest.tspackages/app-data/src/schemas/v1.11.0.jsonpackages/app-data/src/generatedTypes/index.ts
📚 Learning: 2025-06-10T03:06:45.755Z
Learnt from: jeffersonBastos
Repo: cowprotocol/cow-sdk PR: 327
File: packages/app-data/src/schemas/hooks/v0.2.0.json:14-14
Timestamp: 2025-06-10T03:06:45.755Z
Learning: In the CoW Protocol app-data schemas, there are two different version concepts: the schema version (indicated by the filename like v0.2.0.json) represents the schema structure/capability version, while the default version field represents the content/data version for backward compatibility. When new schema versions add optional fields, the default version can remain the same to ensure existing implementations don't break.
Applied to files:
packages/app-data/src/generatedTypes/latest.tspackages/app-data/src/schemas/v1.11.0.jsonpackages/app-data/src/generatedTypes/index.ts
📚 Learning: 2025-06-10T03:06:46.146Z
Learnt from: jeffersonBastos
Repo: cowprotocol/cow-sdk PR: 327
File: packages/app-data/src/schemas/v0.3.0.json:1-10
Timestamp: 2025-06-10T03:06:46.146Z
Learning: Schema versions v0.1.0 through v0.7.0 in the app-data package are intentionally designed to allow additional properties (no "additionalProperties": false constraint), while versions v0.8.0 and later enforce strict validation. This represents a deliberate design evolution and historical schema versions should not be modified to add stricter validation.
Applied to files:
packages/app-data/src/schemas/v1.11.0.jsonpackages/app-data/src/schemas/userConsents/v0.1.0.jsonpackages/app-data/src/generatedTypes/index.tspackages/app-data/src/generatedTypes/v1.11.0.ts
📚 Learning: 2025-06-09T23:25:56.909Z
Learnt from: jeffersonBastos
Repo: cowprotocol/cow-sdk PR: 327
File: packages/app-data/src/schemas/quote/v1.0.0.json:2-2
Timestamp: 2025-06-09T23:25:56.909Z
Learning: In the CoW Protocol app-data schemas, the $id field in JSON schema files doesn't always match the filename version. When schema versions maintain the same fundamental structure, they preserve the same $id as the version that introduced that structure for compatibility purposes. For example, quote schemas v0.3.0, v1.0.0, and v1.1.0 all reference "#quote/v0.2.0.json" in their $id field because they maintain the same core structure as v0.2.0.
Applied to files:
packages/app-data/src/schemas/v1.11.0.json
📚 Learning: 2025-04-14T20:37:56.543Z
Learnt from: anxolin
Repo: cowprotocol/cow-sdk PR: 267
File: src/bridging/BridgingSdk/getCrossChainOrder.ts:44-46
Timestamp: 2025-04-14T20:37:56.543Z
Learning: The decoding of bridge appData (using provider.decodeBridgeHook) in the getCrossChainOrder function was intentionally left as a TODO comment for implementation in a future PR.
Applied to files:
packages/app-data/src/generatedTypes/v1.11.0.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: Build Package
- GitHub Check: Publish to GitHub Packages
- GitHub Check: test
- GitHub Check: eslint
🔇 Additional comments (7)
packages/app-data/src/generatedTypes/latest.ts (1)
3-3: Latest schema pointer updated correctly to v1.11.0.
This keeps the “latest” barrel export aligned with the new schema version.packages/app-data/src/generatedTypes/index.ts (1)
17-45: v1.11.0 wiring + newLATEST_USER_CONSENTS_METADATA_VERSIONexport is coherent.
Imports, constants,LatestAppDataDocVersion, and the union update are consistent.packages/app-data/src/schemas/v1.11.0.json (1)
29-75:metadata.additionalProperties: false+ explicituserConsentsentry is a good strictness upgrade—confirm ref target schema enforces date-time if required.
Root integration ofuserConsentslooks correct; main gap is that the referenced schema currently doesn’t validate date-time unless you addformat.packages/app-data/src/generatedTypes/v1.11.0.ts (1)
190-229:UserConsentstyping matches the current schema, but you probably want stronger schema validation foracceptedDate.
TS will staystringeither way, but schema-side"format": "date-time"is what enforces correctness at validation time.packages/app-data/src/schemas/userConsents/v0.1.0.json (2)
8-11: No action needed—additionalProperties: falsealigns with existing v0.1.0 metadata schema conventions.Analysis of 14 v0.1.0 metadata schemas shows this pattern is neither unusual nor inconsistent: 7 schemas enforce
additionalProperties: false(bridging, flashloan, hook, hooks, partnerFee, replacedOrder, widget), while 7 allow additional properties. The userConsents schema's strict validation on its items object matches the established pattern used by comparable schemas like partnerFee and replacedOrder.
1-26: Addformat: "date-time"foracceptedDate(currently only described, not validated).
Right nowacceptedDateis just a string; if you want actual ISO-8601 date-time validation, add"format": "date-time"."acceptedDate": { "$id": "#/properties/acceptedDate", "type": "string", "description": "ISO 8601 date-time when user accepted the terms in the UI", + "format": "date-time", "examples": ["2025-11-11T23:00:00Z"] }⛔ Skipped due to learnings
Learnt from: jeffersonBastos Repo: cowprotocol/cow-sdk PR: 327 File: packages/app-data/src/schemas/v0.3.0.json:1-10 Timestamp: 2025-06-10T03:06:46.146Z Learning: Schema versions v0.1.0 through v0.7.0 in the app-data package are intentionally designed to allow additional properties (no "additionalProperties": false constraint), while versions v0.8.0 and later enforce strict validation. This represents a deliberate design evolution and historical schema versions should not be modified to add stricter validation.packages/app-data/src/scripts/compile.ts (1)
204-216: Signature extension for'userConsents'looks fine—verify downstream callers/types are regenerated together.
Since this is a public union change, ensure any consumers compile against the regeneratedgeneratedTypes/*output.json-schema-to-typescript compileFromFile options: does it support draft-07 "format": "date-time" in a way that affects generated TS (or is it validation-only)?
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.