-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Cleanup Baseapp tests #1579
Cleanup Baseapp tests #1579
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1579 +/- ##
===========================================
+ Coverage 64.18% 64.53% +0.34%
===========================================
Files 122 122
Lines 6674 6682 +8
===========================================
+ Hits 4284 4312 +28
+ Misses 2145 2125 -20
Partials 245 245 |
Ok, this is ready aside from the changes to not run msg handlers on check tx. It involved some fixes to the baseapp. |
Should I rebase/squash? |
@@ -36,7 +36,7 @@ var isAlpha = regexp.MustCompile(`^[a-zA-Z]+$`).MatchString | |||
// AddRoute - TODO add description | |||
func (rtr *router) AddRoute(r string, h sdk.Handler) Router { | |||
if !isAlpha(r) { | |||
panic("route expressions can only contain alphanumeric characters") | |||
panic("route expressions can only contain alphabet characters") |
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 catch! However I think the regex not allowing numerics is the bug here, not the error message being mismatched. I think there are conceivable reasons for wanting numbers in routers.
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 open a new issue for this
baseapp/baseapp_test.go
Outdated
@@ -270,12 +290,10 @@ type testTx struct { | |||
|
|||
const msgType2 = "testTx" |
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.
Could we add a comment here saying that the point of this is that its a sample message that can fail ValidateBasic?
baseapp/baseapp_test.go
Outdated
return | ||
}) | ||
|
||
tx := testTx{13} |
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 found the 13 here confusing. (Took me a bit to remember where it came from) Maybe we should change testTx from taking in a number to just taking in a bool for whether or not to fail.
fb3e7b1
to
31a1db9
Compare
@ValarDragon thanks for initial review. I rebased on develop and squashed it down to 2 commits. I think some of your comments were addressed in later commits |
It should probably just be one commit |
31a1db9
to
fe7ae11
Compare
baseapp/baseapp.go
Outdated
@@ -534,53 +538,74 @@ func (app *BaseApp) runTx(mode runTxMode, txBytes []byte, tx sdk.Tx) (result sdk | |||
ctx = ctx.WithMultiStore(msCache) | |||
} | |||
|
|||
finalResult := sdk.Result{} | |||
// accumulate results | |||
var logs []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.
Can you do make([]string, 0, len(msgs)
, saves overhead due to expanding the slice.
* simplify mock tx type, msgs, and handlers * remove dependencies on auth and bank * dedup with setupBaseApp * lots of comments and cleanup * fixes where we weren't checking results * use some table driven tests * remove TestValidatorChange - its not testing anything since baseapp doesnt track validator changes * prepare for CheckTx only running the AnteHandler * fix runTx gas handling and add more tests * new tests for multi-msgs
ctx = app.checkState.ctx.WithTxBytes(txBytes) | ||
} else { | ||
ctx = app.deliverState.ctx.WithTxBytes(txBytes) | ||
ctx = ctx.WithSigningValidators(app.signedValidators) |
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.
Maybe I'm unclear on what the purpose of simulate is, but why doesn't it get access to any of the app's signed validators? (How can it simulate how a slashing or staking tx will happen w/o this?)
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.
Yeh good question. The problem is that information is only supplied by BeginBlock, and when we're simulating, we don't know what the next BeginBlock will look like ...
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.
Hrmm. Would it make sense to have an option where its simulated as the last tx in the last known block (for things that depend on headers / validator set), and an option for on the next block (for conceivable things that depend on the exact block height)? This discussion should probably be carried out in a separate issue 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.
Could be useful, although that seems like a rare case - all slashing logic related to signing (downtime / evidence) happens in a BeginBlock
handler, not in transactions.
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.
Baseapp changes LGTM, a few future suggestions but nothing that needs to block merge.
// accumulate results | ||
logs := make([]string, 0, len(msgs)) | ||
var data []byte // NOTE: we just append them all (?!) | ||
var tags sdk.Tags // also just append them all |
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.
tendermint/tendermint#1803 will provide a better option here
} | ||
if !newCtx.IsZero() { | ||
ctx = newCtx | ||
} | ||
gasWanted = anteResult.GasWanted |
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.
Presently the ante handler returns an empty sdk.Result{}
- did we want it to set GasWanted
(to tx.Fee.Gas
presumably)?
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.
Believe so
ctx = app.checkState.ctx.WithTxBytes(txBytes) | ||
} else { | ||
ctx = app.deliverState.ctx.WithTxBytes(txBytes) | ||
ctx = ctx.WithSigningValidators(app.signedValidators) |
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.
Could be useful, although that seems like a rare case - all slashing logic related to signing (downtime / evidence) happens in a BeginBlock
handler, not in transactions.
for i, msg := range msgs { | ||
// accumulate results | ||
logs := make([]string, 0, len(msgs)) | ||
var data []byte // NOTE: we just append them all (?!) |
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'm still not clear what exactly data
and logs
are for, and what the difference between them is intended to be.
At the moment, I think the SDK uses data
in one instance to return a proposal ID (in governance), and doesn't use logs at all. The created proposal ID could just as easily be returned as a tag (probably will be anyways, for later querying) - maybe we can simplify ABCI or what parts of ABCI we use?
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.
log
is intended for non-deterministic output from the app. There is some sense that it would be used to pipe the apps actual logs back to tendermint but I don't think anyone has ever done that.
data
is a deterministic result - we don't really use it AFAIK, so it probably could just be absorbed into tags, but it might be worth keeping for simple apps that want a definitive return value
Working on #1556
Will also likely address #1120 and replace some of #1172