-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
@@ -103,7 +108,7 @@ pub struct OpenTip< | |||
/// scheduled. | |||
closes: Option<BlockNumber>, | |||
/// The members who have voted for this tip. Sorted by AccountId. | |||
tips: Vec<(AccountId, Balance)>, | |||
tips: BoundedVec<(AccountId, Balance), LengthBoundMaximum<Tippers>>, |
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.
Note that I am concerned here about having this BoundedVec controlled by Tippers
, which is a constant used in a different pallet. Chances to make mistakes here could be high.
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 dont see where else this is used
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.
not sure what your response means. I am worried that this tips
pallet has a bounded vec whose limit is the maximum length of the Tippers
. Tippers are defined in the council pallet, which can change in size, potentially smaller.
I wonder if someone will catch that if they reduce the council size, it may corrupt existing state in the tips pallet.
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.
Okay, so the tight coupling here could cause issues.
A test could help with usability, checking that LengthBoundMaximum<Tippers>::get()
has a specific value, but does not solve the problem.
Then a developer would at least spot the broken test and know that something is wrong.
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.
Well, it sounds to me the proper way to fix this is to run a migration whenever the council is reduced in size -- it actually makes sense to remove the vote on the tips whenever the council is reduced in size and hence someone is evicted from being a councilor; it doesn't make sense to still count their vote afterwards.
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.
A migration makes sense, but it is difficult to see that only because you change the DesiredMembers
of the elections provider, you suddenly need a migration in the Tips
pallet…
Some metadata diff tooling could notice this though.
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.
Huh, perhaps then elections provider should provide some lifecycle hook functions so that other pallets can listen in onto the council election event? Sounds like something that would fit this situation without undergoing a migration.
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
Still worth having this. |
cb36cda
to
e57c795
Compare
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
This PR removes
without_storage_info
from Sudo (only use in tests), and the Tips Pallet.