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
New methods enable epochs handler #5491
New methods enable epochs handler #5491
Conversation
…espect with mx-chain-core-go(the method will be removed in a further commit)
// IsFlagDefined checks if a specific flag is supported by the current version of mx-chain-core-go | ||
func (handler *enableEpochsHandler) IsFlagDefined(flag core.EnableEpochFlag) bool { | ||
switch flag { | ||
case core.SCDeployFlag, |
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.
can we instead initialize on the constructor a map with all flags as keys and here just check that the flag is present in the map?
common/interface.go
Outdated
@@ -289,6 +289,11 @@ type EnableEpochsHandler interface { | |||
RefactorPeersMiniBlocksEnableEpoch() uint32 | |||
GetCurrentEpoch() uint32 | |||
|
|||
IsFlagDefined(flag core.EnableEpochFlag) bool | |||
IsFlagEnabledInCurrentEpoch(flag core.EnableEpochFlag) bool |
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.
can we also rename the IsFlagEnabledInCurrentEpoch into IsFlagEnabled?
@@ -39,6 +41,330 @@ func (handler *enableEpochsHandler) EpochConfirmed(epoch uint32, _ uint64) { | |||
handler.epochMut.Unlock() | |||
} | |||
|
|||
// IsFlagDefined checks if a specific flag is supported by the current version of mx-chain-core-go | |||
func (handler *enableEpochsHandler) IsFlagDefined(flag core.EnableEpochFlag) bool { | |||
switch flag { |
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.
instead of this switch, we can have the allFlagsDefined as a map instead of array, as discussed in the last meeting
case core.BelowSignedThresholdFlag: | ||
return epoch >= handler.enableEpochsConfig.BelowSignedThresholdEnableEpoch | ||
case core.SwitchHysteresisForMinNodesFlagInSpecificEpochOnly: | ||
return epoch == handler.enableEpochsConfig.SwitchHysteresisForMinNodesEnableEpoch |
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.
please re-check here, the original code was:
handler.setFlagValue(epoch >= handler.enableEpochsConfig.SwitchHysteresisForMinNodesEnableEpoch, handler.switchHysteresisForMinNodesFlag, "switchHysteresisForMinNodesFlag")
handler.setFlagValue(epoch == handler.enableEpochsConfig.SwitchHysteresisForMinNodesEnableEpoch, handler.switchHysteresisForMinNodesCurrentEpochFlag, "switchHysteresisForMinNodesCurrentEpochFlag")
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.
rechecked: switchHysteresisForMinNodesFlag
(with >=) was returned on IsSwitchHysteresisForMinNodesFlagEnabled
, which was never used, thus I removed it
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.
ok
case core.RepairCallbackFlag: | ||
return epoch >= handler.enableEpochsConfig.RepairCallbackEnableEpoch | ||
case core.ReturnDataToLastTransferFlagAfterEpoch: | ||
return epoch > handler.enableEpochsConfig.ReturnDataToLastTransferEnableEpoch |
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.
missing check for BalanceWaitingListsEnableEpoch
?
handler.setFlagValue(epoch >= handler.enableEpochsConfig.BalanceWaitingListsEnableEpoch, handler.balanceWaitingListsFlag, "balanceWaitingListsFlag")
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.
rechecked: balanceWaitingListsFlag
(with >=) was returned on IsBalanceWaitingListsFlagEnabled
, which was never used, thus I removed it
return epoch >= handler.enableEpochsConfig.ReDelegateBelowMinCheckEnableEpoch | ||
case core.ValidatorToDelegationFlag: | ||
return epoch >= handler.enableEpochsConfig.ValidatorToDelegationEnableEpoch | ||
case core.IncrementSCRNonceInMultiTransferFlag: |
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.
missing check for WaitingListFixEnableEpoch
?
handler.setFlagValue(epoch >= handler.enableEpochsConfig.WaitingListFixEnableEpoch, handler.waitingListFixFlag, "waitingListFixFlag")
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.
rechecked: waitingListFixFlag
(with >=) was returned on IsWaitingListFixFlagEnabled
, which was never used, thus I removed it
case core.IncrementSCRNonceInMultiTransferFlag: | ||
return epoch >= handler.enableEpochsConfig.IncrementSCRNonceInMultiTransferEnableEpoch | ||
case core.ESDTMultiTransferFlag, | ||
core.ESDTNFTImprovementV1Flag: |
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.
what is ESDTNFTImprovementV1Flag
?
In the original code I do not see 2 flags related to the same ESDTMultiTransferEnableEpoch
. Please re-check
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 remember we had a discussion for these methods that rely on the same flag, to better create a new method with an appropriate naming, rather than reuse the same method
This led to the following methods, which are marked as duplicate:
https://github.com/multiversx/mx-chain-go/blob/rc/v1.6.0/common/enablers/epochFlags.go#L634
With this new approach, I had to create a new flag for them
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.
ok
case core.ESDTTransferRoleFlag: | ||
return epoch >= handler.enableEpochsConfig.ESDTTransferRoleEnableEpoch | ||
case core.BuiltInFunctionOnMetaFlag, | ||
core.TransferToMetaFlag: |
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, is this a new flag? In the original code I do not see 2 flags coupled with the same BuiltInFunctionOnMetaEnableEpoch
value
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.
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.
ok
return epoch >= handler.enableEpochsConfig.CorrectFirstQueuedEpoch | ||
case core.DeleteDelegatorAfterClaimRewardsFlag: | ||
return epoch >= handler.enableEpochsConfig.DeleteDelegatorAfterClaimRewardsEnableEpoch | ||
case core.RemoveNonUpdatedStorageFlag: |
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.
missing check for FixOOGReturnCodeEnableEpoch
?
handler.setFlagValue(epoch >= handler.enableEpochsConfig.FixOOGReturnCodeEnableEpoch, handler.fixOOGReturnCodeFlag, "fixOOGReturnCodeFlag")
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.
check exists on L360, flag is FixOOGReturnCodeFlag
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.
right, missed it due to the changed position
case core.RemoveNonUpdatedStorageFlag: | ||
return epoch >= handler.enableEpochsConfig.RemoveNonUpdatedStorageEnableEpoch | ||
case core.OptimizeNFTStoreFlag, | ||
core.SaveToSystemAccountFlag, |
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.
are SaveToSystemAccountFlag
, CheckFrozenCollectionFlag
, ValueLengthCheckFlag
, CheckTransferFlag
new flags? I do not see them on the original code coupled to OptimizeNFTStoreEnableEpoch
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.
they are all duplicated as mentioned above:
return epoch >= handler.enableEpochsConfig.MiniBlockPartialExecutionEnableEpoch | ||
case core.ManagedCryptoAPIsFlag: | ||
return epoch >= handler.enableEpochsConfig.ManagedCryptoAPIsEnableEpoch | ||
case core.ESDTMetadataContinuousCleanupFlag, |
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.
on the original code, I see this epoch flag tight only to esdtMetadataContinuousCleanupFlag
and changeDelegationOwnerFlag
. Is this 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.
same as above, duplicated for consistency: https://github.com/multiversx/mx-chain-go/blob/rc/v1.6.0/common/enablers/epochFlags.go#L610
case core.FixOOGReturnCodeFlag: | ||
return epoch >= handler.enableEpochsConfig.FixOOGReturnCodeEnableEpoch | ||
case core.DeterministicSortOnValidatorsInfoFixFlag: | ||
return epoch >= handler.enableEpochsConfig.DeterministicSortOnValidatorsInfoEnableEpoch |
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.
missing check for DynamicGasCostForDataTrieStorageLoadEnableEpoch
? (might need a new update branch operation)
handler.setFlagValue(epoch >= handler.enableEpochsConfig.DynamicGasCostForDataTrieStorageLoadEnableEpoch, handler.dynamicGasCostForDataTrieStorageLoadFlag, "dynamicGasCostForDataTrieStorageLoadFlag", epoch, handler.enableEpochsConfig.DynamicGasCostForDataTrieStorageLoadEnableEpoch)
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.
indeed this one is missing due to a missing update branch.. added TODO to be fixed after merge from rc/v1.6.0
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## feat/refactor_enable_epochs_handler #5491 +/- ##
=======================================================================
+ Coverage 80.09% 80.27% +0.18%
=======================================================================
Files 703 706 +3
Lines 92715 93726 +1011
=======================================================================
+ Hits 74263 75242 +979
- Misses 13161 13195 +34
+ Partials 5291 5289 -2
☔ View full report in Codecov by Sentry. |
@@ -365,6 +371,12 @@ func (handler *enableEpochsHandler) IsFlagEnabledInEpoch(flag core.EnableEpochFl | |||
} | |||
} | |||
|
|||
// GetActivationEpoch returns the activation epoch of the provided flag | |||
func (handler *enableEpochsHandler) GetActivationEpoch(flag core.EnableEpochFlag) uint32 { |
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.
interesting, this can be helpful if exposed on the API routes
@@ -289,6 +289,12 @@ type EnableEpochsHandler interface { | |||
RefactorPeersMiniBlocksEnableEpoch() uint32 | |||
GetCurrentEpoch() uint32 | |||
|
|||
IsFlagDefined(flag core.EnableEpochFlag) bool |
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.
will you remove the ...EnableEpoch() and IsFlag...() methods in a subsequent PR?
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.
exactly, once all of them are replaced with calls to new ones
"github.com/multiversx/mx-chain-go/config" | ||
"github.com/multiversx/mx-chain-go/process" | ||
logger "github.com/multiversx/mx-chain-logger-go" | ||
) | ||
|
||
var log = logger.GetOrCreate("common/enablers") | ||
|
||
var allFlagsDefined = map[core.EnableEpochFlag]struct{}{ | ||
common.SCDeployFlag: {}, |
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.
maybe add here the handler for checking if the flag is enabled in the given epoch as value?
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.
updated as discussed
@@ -248,8 +248,7 @@ func (tdt *trackableDataTrie) updateTrie(dtr state.DataTrie) ([]core.TrieData, e | |||
} | |||
|
|||
func (tdt *trackableDataTrie) retrieveValueFromTrie(key []byte) (core.TrieData, uint32, error) { | |||
currentEpoch := tdt.enableEpochsHandler.GetCurrentEpoch() | |||
if tdt.enableEpochsHandler.IsAutoBalanceDataTriesEnabledInEpoch(currentEpoch) { | |||
if tdt.enableEpochsHandler.IsFlagEnabled(common.AutoBalanceDataTriesFlag) { |
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 think we should add for each subcomponent also the compatibility check, to find out early that the handlers for finding that a flag is enabled are defined in the map.
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.
added TODO for this and I'll add the checks in the further PRs, while replacing the calls(easier to extract exactly what flags the specific subcomponent needs)
55a8449
into
feat/refactor_enable_epochs_handler
Reasoning behind the pull request
Proposed changes
Testing procedure
Pre-requisites
Based on the Contributing Guidelines the PR author and the reviewers must check the following requirements are met:
feat
branch created?feat
branch merging, do all satellite projects have a proper tag insidego.mod
?