This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
update_lock
expects thatinc_consumers
cannot fail if the account is funded, an assumption which theMaxConsumers
limit breaks.This introduce a new function
inc_consumers_without_limit
, which provides the old functionality. This makesMaxConsumers
a soft limit, able to be breached under limited situations. Specifically, the actual maximum number of consumers isMaxConsumers
plus the callable instances ofinc_consumers_without_limit
, which for the Polkadot chain is1
(owing to the single instance of theLocks
pallet).For now we default to just doubling it in the case of a single
ConstU32
MaxConsumers
definition which is fine for anything non-production. For live chains, we might want to tailor it a little more using the pair-Get
ter impl. It doesn't really matter yet as the benchmarks don't take this into account. The main thing is to ensure the numbers stay low enough that sorting isn't going to be a major cost.