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

x/superfluid: ensure events are emitted and tests added #2255

Merged
merged 25 commits into from
Sep 3, 2022
Merged

x/superfluid: ensure events are emitted and tests added #2255

merged 25 commits into from
Sep 3, 2022

Conversation

hieuvubk
Copy link
Contributor

Closes: #2194

What is the purpose of the change

Brief Changelog

  • Refactor and unit test superfluid module events
  • Write test to make sure events emitted in right place
  • Update readme

Testing and Verifying

This change added tests and can be verified as follows:

  • Internal events unit tests
  • msg server tests

Documentation and Release Note

  • Does this pull request introduce a new feature or user-facing behavior changes? (yes / no)
  • Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? (yes / no)
  • How is the feature or change documented? (not applicable / specification (x/<module>/spec/) / Osmosis docs repo / not documented)

@hieuvubk hieuvubk requested a review from a team July 29, 2022 12:40
@github-actions github-actions bot added C:docs Improvements or additions to documentation C:x/superfluid labels Jul 29, 2022
Copy link
Member

@p0mvn p0mvn left a comment

Choose a reason for hiding this comment

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

LGTM.

I verified that all attributes are preserved and the locations of where events are emitted are not changed.

Phenomenal work on this @hieuvubk ! and thank you for documenting it all!

x/superfluid/README.md Outdated Show resolved Hide resolved
x/superfluid/README.md Outdated Show resolved Hide resolved
x/superfluid/README.md Outdated Show resolved Hide resolved
x/superfluid/README.md Outdated Show resolved Hide resolved
x/superfluid/keeper/gov/suite_test.go Outdated Show resolved Hide resolved
x/superfluid/keeper/internal/events/emit.go Show resolved Hide resolved
sdk.NewAttribute(types.AttributeLockId, fmt.Sprintf("%d", msg.LockId)),
))
if err == nil {
events.EmitSuperfluidUnbondLockEvent(ctx, msg.LockId)
}
return &types.MsgSuperfluidUnbondLockResponse{}, err
Copy link
Member

Choose a reason for hiding this comment

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

q: should we also be emitting thesdk.EventTypeMessage event at the end of every message similar to GAMM?

cc: @mattverse @ValarDragon @alexanderbez

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah we should use typed events for each message execution. We should also consider populating MsgSuperfluidUnbondLockResponse with relevant fields.

@p0mvn
Copy link
Member

p0mvn commented Jul 29, 2022

I would like to have one more reviewer give this a look before merging since the diff is large. Overall, the change LGTM. Also, I left a comment for follow-up work that would be good to decide on

@@ -59,6 +59,7 @@ func (suite *KeeperTestSuite) TestHandleSetSuperfluidAssetsProposal() {
assets []types.SuperfluidAsset
expectedAssets []types.SuperfluidAsset
expectErr bool
expectedEvent string
}
testCases := []struct {
Copy link
Member

Choose a reason for hiding this comment

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

Are we able to / should we break down this actions struct by item? Maybe its not a big deal but just seeing a lump of five items together doesn't make the table driven test super easy to figure out what is getting tested.

Copy link
Member

Choose a reason for hiding this comment

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

Good idea, naming fields is preferable for readability IMO

x/superfluid/keeper/internal/events/emit.go Show resolved Hide resolved
x/superfluid/keeper/msg_server_test.go Outdated Show resolved Hide resolved
@hieuvubk hieuvubk requested a review from czarcas7ic August 1, 2022 02:40
types.TypeEvtSetSuperfluidAsset,
sdk.NewAttribute(types.AttributeDenom, denom),
sdk.NewAttribute(types.AttributeSuperfluidAssetType, assetType.String()),
)
Copy link
Contributor

@stackman27 stackman27 Aug 2, 2022

Choose a reason for hiding this comment

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

Since we are going over all the module events, what are the thoughts on using EmitTypedEvent instead of EmitEvents

It'll definitely reduce the code size and gives a better code clarity. For instance the above code could be rewritten with an event.proto file as;

ctx.EventManager().EmitTypedEvent(&superfluid.AssetEvent{
		denom:  denom,
	         assetType: assetType.String(), 
	})

ps: EmitEvents is labelled deprecated too

cc @alexanderbez @ValarDragon @p0mvn

Copy link
Member

@p0mvn p0mvn Aug 3, 2022

Choose a reason for hiding this comment

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

Yes, I think that's a great idea. However, I'm guessing we would make the EmitEvent function reusable across modules instead of defining this on the event manager. What do you think?

Also, I think we would have to make the event constructors exported.

For example, newSetSuperfluidAssetEvent -> NewSetSuperfluidAssetEvent

To have:

EmitEvent(NewSuperfluidAssetEvent(...))

Just to avoid any confusion - we should pursue this separately (not in this PR)

Copy link
Contributor

Choose a reason for hiding this comment

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

Are we reusing events? I would only use constructors and separate out the event logic if we use the same ones in multiple places, otherwise it would be overkill.

Copy link
Member

@ValarDragon ValarDragon Aug 4, 2022

Choose a reason for hiding this comment

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

We are in 0 rush to switch to typed events.

I also agree that constructors seem overkill unless reuse

}

func EmitSuperfluidUnbondLockEvent(ctx sdk.Context, lockId uint64) {
if ctx.EventManager() == nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

EventManager should never be nil, but I guess it can't hurt. Just so many LOC :-/

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ahh thank you. If so, I'll remove them.

@@ -455,7 +455,88 @@ Disable multiple assets from being used for superfluid staking.

## Events
Copy link
Contributor

Choose a reason for hiding this comment

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

I love the motivation for this, but I can see this going out of date and being difficult to maintain.

Copy link
Member

Choose a reason for hiding this comment

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

I think we might still want to have it since these docs get auto-uploaded to the docs website. Currently, there is no info about events but it could be useful for integrators. WDYT?

@github-actions github-actions bot added C:app-wiring Changes to the app folder C:CLI C:simulator Edits simulator or simulations C:x/gamm Changes, features and bugs related to the gamm module. C:x/incentives C:x/lockup C:x/mint C:x/tokenfactory labels Aug 4, 2022
@github-actions github-actions bot removed C:simulator Edits simulator or simulations C:x/lockup T:CI T:build C:CLI labels Aug 4, 2022

// TestMsgSuperfluidDelegate_Event tests that events are correctly emitted
// when calling SuperfluidDelegate.
func (suite *KeeperTestSuite) TestMsgSuperfluidDelegate_Event() {
Copy link
Contributor

@stackman27 stackman27 Aug 10, 2022

Choose a reason for hiding this comment

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

I noticed that events tests are very identical to their actual tests and there is repetitive code in tests like (TestMsgSuperfluidDelegate and TestMsgSuperfluidDelegate_Event)

is there any way we can just use one?

}
}

func assertEventEmitted(suite *KeeperTestSuite, ctx sdk.Context, eventTypeExpected string, numEventsExpected int) {
Copy link
Contributor

Choose a reason for hiding this comment

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

this function has been defined in app/apptesting/events.go pretty sure we can just use that

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for reminding


if test.expectPass {
suite.Require().NoError(err)
assertEventEmitted(suite, suite.Ctx, types.TypeEvtSuperfluidDelegate, 1)
Copy link
Contributor

Choose a reason for hiding this comment

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

why do you need to pass Suite and Suite.Ctx? You can just get the context if you pass Suite

@hieuvubk hieuvubk requested a review from stackman27 August 11, 2022 06:03
"github.com/osmosis-labs/osmosis/v10/x/superfluid/types"
)

type SuperfluidEventsTestSuite struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

Just wondering, what was the motivation behind create a new test suite? Can't we just use the KeeperTestSuite?

cc @p0mvn

addressString = "addr1---------------"
testDenomA = "denoma"
testDenomB = "denomb"
testDenomC = "denomc"
Copy link
Contributor

Choose a reason for hiding this comment

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

this seems to be unused

testDenomA = "denoma"
testDenomB = "denomb"
testDenomC = "denomc"
testDenomD = "denomd"
Copy link
Contributor

Choose a reason for hiding this comment

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

this seems to be unused

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thank you

@hieuvubk hieuvubk requested a review from stackman27 August 27, 2022 08:18
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.

LGTM

I do have the same general point of I think this should be managed by the framework / we shouldn't do more of this, but I think this is good to merge in!

Thanks for the fix, and sorry this got blocked for so long

@ValarDragon ValarDragon merged commit 0212dee into osmosis-labs:main Sep 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:docs Improvements or additions to documentation C:x/superfluid
Projects
None yet
Development

Successfully merging this pull request may close these issues.

x/superfluid: ensure events are emitted and tests added
6 participants