-
Notifications
You must be signed in to change notification settings - Fork 24
[Provider Context] Update provider creation to intake new payload + changes around it #2537
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Provider Context] Update provider creation to intake new payload + changes around it #2537
Conversation
| /// - [`Error::ExceedsMaxProviderNameSize`] - Too long of a provider name | ||
| #[pallet::call_index(11)] | ||
| #[pallet::weight(T::WeightInfo::propose_to_be_provider())] | ||
| #[pallet::weight(T::WeightInfo::propose_to_be_provider_v2())] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| #[pallet::weight(T::WeightInfo::propose_to_be_provider_v2())] | |
| #[pallet::weight(T::WeightInfo::propose_to_be_provider())] |
I think this is the original, not the v2, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or are we just using the same weights for both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume we can since its calling underlying extrinsic (re-routing after size check), you suggest we have separate benchmarks for both?
| /// * [`Error::DuplicateProviderRegistryEntry`] - a ProviderRegistryEntry associated with the given MSA id already exists. | ||
| #[pallet::call_index(12)] | ||
| #[pallet::weight(T::WeightInfo::create_provider_via_governance())] | ||
| #[pallet::weight(T::WeightInfo::create_provider_via_governance_v2())] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same question as above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thoughts, we have bench marked v2 in this case and v1 extrinsic just re-route call to v2 with default payload, not sure if we should benchmark both
JoeCap08055
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some nits leftover, but nothing blocking
nice work!
f673341
into
feat/provider-context-development
Goal
This PR introduces changes required to support the new Provider Context model as outlined in the Provider Contexts Design Doc. It updates the structure and handling of providers to allow them to represent a company with one or more applications, supporting internationalized metadata and trusted branding via content-addressed hashes.
Closes #2523
Summary of Changes
Registry and Extrinsics
Updated ProviderRegistryEntry:
Replaces the old struct name with a new struct supporting:
default_name: BoundedString
default_logo: Option
localized_name: BoundedBTreeMap<LanguageCode, BoundedString>
localized_logo: BoundedBTreeMap<LanguageCode, Cid>
Updated propose_to_be_provider extrinsic:
Updated create_provider_by_governance extrinsic
Updated create_provider extrinsic
Updated Benchmarks
Updated Unit tests/e2e tests
Added e2e tests
Added unit tests
Added
ProviderToRegistryEntryto migration to storage version2Tested try-runtime migration with
PaseoandMainnetand it worksIn progress
Checklist
Snaps
on_runtime_upgradevia try-runtime cli on paseo