Skip to content
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

chore: twap mutation fixes part 1 #2468

Merged
merged 20 commits into from
Aug 23, 2022
Merged

chore: twap mutation fixes part 1 #2468

merged 20 commits into from
Aug 23, 2022

Conversation

czarcas7ic
Copy link
Member

@czarcas7ic czarcas7ic commented Aug 19, 2022

Part Of: #2426

What is the purpose of the change

This PR brings the mutation test score for the twap module from ~33% to ~46%

PRing this now to prevent a large diff for the next / upcoming mutation fixes

Brief Changelog

  • Adds RunBasicJoin as a GAMM keeper test helper
  • Corrects lexicographical order of twap denoms
    • getMostRecentRecord switches order
    • also checks that the denoms are not equal
  • Removes ordering from GetBeginBlockAccumulatorRecord (this is done in getMostRecentRecord which this function calls/returns. Better to have the logic at the higher level)
  • Improves TestGetBeginBlockAccumulatorRecord

Testing and Verifying

This change is already covered by existing tests

Documentation and Release Note

  • Does this pull request introduce a new feature or user-facing behavior changes? no
  • Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? no
  • How is the feature or change documented? not applicable

@github-actions github-actions bot added C:app-wiring Changes to the app folder C:x/twap Changes to the twap module labels Aug 19, 2022
x/twap/types/utils.go Show resolved Hide resolved
x/twap/types/utils.go Show resolved Hide resolved
// correct ordering of args for db
if asset1Denom > asset0Denom {
asset0Denom, asset1Denom = asset1Denom, asset0Denom
}
return k.getMostRecentRecord(ctx, poolId, asset0Denom, asset1Denom)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to reviewer: This gets checked/modified in getMostRecentRecord which is called in the return statement which is why I removed it here.

@@ -27,16 +28,18 @@ func (s *TestSuite) TestGetBeginBlockAccumulatorRecord() {
poolId uint64
quoteDenom string
baseDenom string
expError bool
expError error
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to reviewer: changed this to specific error type since I realized things were passing with an error, but not the right error we desired. Might want to eventually have an errors type file in twap so we can specify specific error codes instead of manually specifying expected errors here

Copy link
Member

@ValarDragon ValarDragon Aug 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we should make error types. (Lets not do that move this PR, other parallel PRs will conflict that change that logic) We don't need a code though, golang errors.Is will suffice for our usecase here

@@ -41,7 +41,7 @@ func (s *TestSuite) SetupTest() {
// sets up a new two asset pool, with spot price 1
func (s *TestSuite) setupDefaultPool() (poolId uint64, denomA, denomB string) {
poolId = s.PrepareUni2PoolWithAssets(defaultUniV2Coins[0], defaultUniV2Coins[1])
denomA, denomB = defaultUniV2Coins[1].Denom, defaultUniV2Coins[0].Denom
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to reviewer: This is where a majority of the issue was coming from, we were setting denomA as if it were lexicographically smaller when in reality it was the larger.

@@ -50,6 +50,7 @@ func (s *TestSuite) TestSwapAndEndBlockTriggeringSave() {
s.Commit() // clear transient store
// Now on a clean state after a create pool
s.Require().Equal(baseTime.Add(time.Second), s.Ctx.BlockTime())
s.RunBasicJoin(poolId)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note to reviewer: This is needed to test the JoinPool twap hook (mutation tests caught this!)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Err, this should be its own test. We need to test on a clean instance, a join in a block will trigger the end tracking.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@czarcas7ic czarcas7ic marked this pull request as ready for review August 19, 2022 23:56
@czarcas7ic czarcas7ic requested a review from a team August 19, 2022 23:56
Copy link
Member

@ValarDragon ValarDragon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job! Using the right order + this helper really cleans things up!

One change needed for the RunBasicJoin test, then I think its good to merge :)

czarcas7ic and others added 3 commits August 21, 2022 15:14
Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com>
app/apptesting/gamm.go Show resolved Hide resolved
Comment on lines 50 to 53
denomPairs0, denomPairs1 := types.GetAllUniqueDenomPairs(denoms)
expectedRecords := []types.TwapRecord{}
for i := 0; i < len(denomPairs0); i++ {
expectedRecord, err := types.NewTwapRecord(s.App.GAMMKeeper, s.Ctx, poolId, denomPairs0[i], denomPairs1[i])
for i := len(denomPairs0); i < 0; i-- {
expectedRecord, err := twap.NewTwapRecord(s.App.GAMMKeeper, s.Ctx, poolId, denomPairs0[i], denomPairs1[i])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we iterating in reverse order?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized why I thought this was necessary. GetAllUniqueDenomPairs returns the denom pairs in non lexicographical order and NewTwapRecord auto rearranges them. Then when we get down to GetMostRecentRecordStoreRepresentation, the order of input matters and does not get auto corrected. I am correcting this now

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, fixed in most recent commit. Will need to write in spec about these guarantees still though

Comment on lines -14 to -16
if !(denom0 > denom1) {
return TwapRecord{}, fmt.Errorf("precondition denom0 > denom1 not satisfied. denom0 %s | denom1 %s", denom0, denom1)
}
Copy link
Member

@ValarDragon ValarDragon Aug 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we remove this check here, I think we need to be clear in the spec / code comments about guarantees we expect. (Which methods expect correct order, which ones will swap order)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@czarcas7ic czarcas7ic self-assigned this Aug 22, 2022
@github-actions github-actions bot added the C:docs Improvements or additions to documentation label Aug 22, 2022
x/twap/README.md Outdated
Comment on lines 66 to 67
All functions that call `LexicographicalOrderDenoms` (such as `getMostRecentRecordStoreRepresentation`, `getRecordAtOrBeforeTime`, and `NewTwapRecord`), both directly and indirectly, will swap the provided denoms to be in ascending lexicographical order. This means that regardless of input, asset0Denom is guaranteed to be lexicographically smaller than asset1Denom.
If this does not occur, an error will be returned, likely indicating that the two denoms provided are equivalent (which is not allowed).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

err, this doesn;t really make sense at the spec level / at least not the API layer: Its an abstraction leak for the caller! It would only apply for the store layer.

@ValarDragon ValarDragon merged commit 26d23ef into main Aug 23, 2022
@ValarDragon ValarDragon deleted the adam/twap-mutation-1 branch August 23, 2022 00:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:app-wiring Changes to the app folder C:docs Improvements or additions to documentation C:x/twap Changes to the twap module
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants