refactor: end block ordering - staking after gov and module sorting #2937
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.
Closes: #XXX
What is the purpose of the change
ModuleNames()
function returns modules in non-deterministic order due to a map iteration. Our DAG took those modules to construct total order from a partial order. Although we tried to sort the module names to prevent non-determinism, we ended up erroneously providing the unsorted copy.Additionally, there was no ordering constraint for the staking
EndBlock
to go after the govEndBlock
. The constraint is added here.It seems that the DAG ordering problems haven't been causing issues since they were added. The ordering between stake and gov modules only matters in some edge cases. In our case, the following proposal has led to the dependency being fatal: https://www.mintscan.io/osmosis/proposals/337
Lastly, @alexanderbez created a test to make sure that the ordering is deterministic.
Testing and Verifying
This change added tests.
Documentation and Release Note
Unreleased
section inCHANGELOG.md
? no