-
Notifications
You must be signed in to change notification settings - Fork 105
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
fix: skip logging during ante simulation #1263
Conversation
x/ante/ante.go
Outdated
ctx.BlockHeight(), | ||
string(d.cdc.MustMarshalJSON(msg)), | ||
)) | ||
if !simulate { |
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 simulate { return...} to avoid unnecessary nested if blocks
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.
That would duplicate the next
call at the end 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.
which is fine
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.
Code duplication seems worse (especially related to ante handle checks) compared to a bit more nesting
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 strongly disagree, especially in golang. Do you wanna start seeing?!
if err := ...; err == nil {
if err := ...; err == nil {
if err := ...; err == nil {
...
}
}
}
return ...
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.
What exactly makes you think this kind of duplicate is bad? What makes ante handler special in this case?
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.
nested-ifs compared to early exit creates the very problem that when someone reads it, he has to figure out what happens if simulate
is true
by scrolling down the entire block to just find out nothing is gonna happen. It's confusing and unreadable. When one sees if simulate { return ... }
, it's clear immediately that this function isn't gonna do anything when simulate
is set to true
(no logging, no mutation to ctx, no nothing) and also makes a lot of sense since logging shouldn't happen if in the simulation mode.
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.
Updated it. I get the benefit of early returns on failure cases. But in this case, it's not a failure, so requires duplication of logic. My concern is if someone changes the logic of next
at the end, they need to remember to do this for the early exit too. This is specifically concerning for ante handle checks since they perform some authentication and are critical. The vote module had a duplication related bug like this if I recall. But anyways, up to you, since I haven't coded in Go much.
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.
They wouldn't need to remember to do anything to the early exit. The whole point here is that we wanna make sure NOTHING should ever happen in the logging ante handler if simuate is true. If they have to do something to the early exit, I can see a lot of stuff being questionable about what that person is doing.
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.
ante handler isn't anything special. It's just like middlewares in express.js or interceptors in gRPC.
Description
Todos
Steps to Test
Expected Behaviour
Other Notes