-
Notifications
You must be signed in to change notification settings - Fork 608
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
x/superfluid: ensure events are emitted and tests added #2255
Conversation
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.
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!
sdk.NewAttribute(types.AttributeLockId, fmt.Sprintf("%d", msg.LockId)), | ||
)) | ||
if err == nil { | ||
events.EmitSuperfluidUnbondLockEvent(ctx, msg.LockId) | ||
} | ||
return &types.MsgSuperfluidUnbondLockResponse{}, err |
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.
q: should we also be emitting thesdk.EventTypeMessage
event at the end of every message similar to GAMM?
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.
Yeah we should use typed events for each message execution. We should also consider populating MsgSuperfluidUnbondLockResponse
with relevant fields.
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 { |
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 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.
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.
Good idea, naming fields is preferable for readability IMO
types.TypeEvtSetSuperfluidAsset, | ||
sdk.NewAttribute(types.AttributeDenom, denom), | ||
sdk.NewAttribute(types.AttributeSuperfluidAssetType, assetType.String()), | ||
) |
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.
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
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.
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)
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 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.
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.
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 { |
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.
EventManager
should never be nil, but I guess it can't hurt. Just so many LOC :-/
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.
Ahh thank you. If so, I'll remove them.
@@ -455,7 +455,88 @@ Disable multiple assets from being used for superfluid staking. | |||
|
|||
## Events |
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 love the motivation for this, but I can see this going out of date and being difficult to maintain.
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 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?
merge main
|
||
// TestMsgSuperfluidDelegate_Event tests that events are correctly emitted | ||
// when calling SuperfluidDelegate. | ||
func (suite *KeeperTestSuite) TestMsgSuperfluidDelegate_Event() { |
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 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) { |
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.
this function has been defined in app/apptesting/events.go
pretty sure we can just use that
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.
Thanks for reminding
|
||
if test.expectPass { | ||
suite.Require().NoError(err) | ||
assertEventEmitted(suite, suite.Ctx, types.TypeEvtSuperfluidDelegate, 1) |
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.
why do you need to pass Suite
and Suite.Ctx
? You can just get the context if you pass Suite
"github.com/osmosis-labs/osmosis/v10/x/superfluid/types" | ||
) | ||
|
||
type SuperfluidEventsTestSuite struct { |
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.
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" |
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.
this seems to be unused
testDenomA = "denoma" | ||
testDenomB = "denomb" | ||
testDenomC = "denomc" | ||
testDenomD = "denomd" |
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.
this seems to be unused
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.
thank you
Co-authored-by: Sishir Giri <[email protected]>
merge main
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.
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
Closes: #2194
What is the purpose of the change
Brief Changelog
Testing and Verifying
This change added tests and can be verified as follows:
Documentation and Release Note
Unreleased
section inCHANGELOG.md
? (yes / no)x/<module>/spec/
) / Osmosis docs repo / not documented)