-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
feat: make authz MsgExec emit events from all executed msgs #9522
Conversation
Codecov Report
@@ Coverage Diff @@
## master #9522 +/- ##
===========================================
+ Coverage 35.48% 60.60% +25.12%
===========================================
Files 332 589 +257
Lines 32620 37236 +4616
===========================================
+ Hits 11575 22567 +10992
+ Misses 19819 12726 -7093
- Partials 1226 1943 +717
|
Can we also emit general event attributes like other module messages are emitting
but authz only is emitting
|
Currently I have the following being emitted after a MsgExec using bank's MsgSend on my branch:
Does this cover your needs for the issue? Let me know if there is more and I'll look into it further @YunSuk-Yeo |
@YunSuk-Yeo the This task is to make sure that the |
Yea actually updated events are enough, but just want to sure the consistency with other modules. |
for i := 0; i < len(events); i++ { | ||
sdkEvents = append(sdkEvents, sdk.Event(events[i])) | ||
} | ||
ctx.EventManager().EmitEvents(sdkEvents) |
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.
PR looks good to me, but I actually don't understand why the underlying Msg's events are not emitted in the first place?
L112 we call msgResult, err = handler(ctx, msg)
, that that should call ctx.EventManager.EmitEvents()
already.
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 it's because MsgExec runs its tx messages directly through tendermint/ABCI rather than the SDK handlers? Thats the gist i got from digging into 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.
Let's make sure we dig through the logic in the router and BaseApp and understand what's happening well
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.
Checked some more and looks like this code overwrites the current event manager in context, which i assume could be a culprit here. I added a nil check before allowing that code to run (it was never nil in my tests).
Curiously though, it duplicated the attributes in the events. For example a transfer event had 6 attributes instead of 3 (the 3 were just duplicates, not different key/vals) Haven't had much luck figuring out why that happens though
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.
If we removed that line in msg_service_router.go
, and reverted all changes in this PR, does that still emit duplicates?
It seems to me that would be a better fix?
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 when i ran my test i had commented out the event emission i added in DispatchEvents
. For some messages though, not everything was simply a duplicate, for instance MsgExec's event only had duplicated the sender
attribute, but nothing else.
also looking at this again, im noticing not every event has an exact duplicate - for example the transfer event has 2 different recipient addresses, however sender and amount are both exact copies.
x/auth/tx/service_test.go
Outdated
@@ -565,6 +567,110 @@ func (s *IntegrationTestSuite) TestSimMultiSigTx() { | |||
s.Require().Greater(res.GasInfo.GasUsed, uint64(0)) | |||
} | |||
|
|||
// Tests that all msg events included in an authz MsgExec tx | |||
// Ref: https://github.com/cosmos/cosmos-sdk/issues/9501 | |||
func (s *IntegrationTestSuite) TestSim_MsgExecEvents() { |
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 this test should be in x/authz
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.
pre-approving pending on Robert's comments on the test. Actual fix looks okay to me, though if we merge this we should also create an issue to understand #9522 (comment) better
[digression] Tests in SDK is a big mess - I know the fastest way is to find a similar patter and copy paste. So adding better example tests is important for future maintainability. Also tests with CLI are slower to execute. |
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.
Looks good. Left few suggestions.
x/authz/keeper/keeper_test.go
Outdated
granterAddr := addrs[0] | ||
granteeAddr := addrs[1] | ||
recipientAddr := addrs[2] | ||
s.Require().NoError(simapp.FundAccount(app.BankKeeper, s.ctx, granterAddr, sdk.NewCoins(sdk.NewInt64Coin("steak", 10000)))) |
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 using FundAccount
Description
Closes: #9501
This PR makes MsgExec emit all events from each executed message. Adds a test to check for the additional events.
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeadded a changelog entry toN/ACHANGELOG.md
updated the relevant documentation or specificationN/AReviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change