-
Notifications
You must be signed in to change notification settings - Fork 970
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
Protocol 19 - CAP-0021 and CAP-0040 #3377
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.
only did a partial review, found a few bugs
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 completed my first review pass, I will do another one after this gets rebased on top of master when we have merged the tests refactor (that adds quite a bit of noise)
return true; | ||
} | ||
|
||
if (mEnvelope.type() == ENVELOPE_TYPE_TX && |
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.
you don't need to check for mEnvelope.type() == ENVELOPE_TYPE_TX
here (getMinSeqNum
takes care of 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.
Reviewed up to "Updated tx queue and txset validation". I think the next part is going to take quite a bit more time, so I wanted to add the comments I already had.
f0ea865
to
eb70364
Compare
else | ||
{ | ||
ltxe.currentGeneralized().maxSeqNumToApplyEntry().maxSeqNum = | ||
getSeqNum(); |
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 assumes processFeeSeqNum
is called with increasing sequence numbers per source account. This is true at the moment, but it might be a good idea to use std::max
or throw if the sequence numbers aren't increasing.
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 agree... at the same time, why not just use max
now then as it makes it clear that this is the max over all txs for that source?
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.
Done
else | ||
{ | ||
ltxe.currentGeneralized().maxSeqNumToApplyEntry().maxSeqNum = | ||
getSeqNum(); |
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 agree... at the same time, why not just use max
now then as it makes it clear that this is the max over all txs for that source?
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.
getting close!
55bed5f
to
ce547ea
Compare
cf891f2
to
6e3997a
Compare
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've reviewed everything but the tests, and this generally looks good. I will spend some time reviewing the tests in the next few days, but I didn't want to hold up the whole PR over that.
My main concern is that the KeyUtils changes are so difficult to understand and evaluate. It's really hard to follow every path down and assess that only sane things are happening. I know that #3397 is already about this, but I wanted to reiterate that it makes me uneasy. We should strongly consider addressing this as soon as possible.
src/ledger/LedgerManagerImpl.cpp
Outdated
@@ -1128,8 +1128,12 @@ LedgerManagerImpl::processFeesSeqNums( | |||
} | |||
else | |||
{ | |||
throw std::runtime_error( | |||
"found unexpected MAX_SEQ_NUM_TO_APPLY"); | |||
ltxe.currentGeneralized() |
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 a bit skeptical about this. This would_definitely be a bug, and hiding bugs is scary because you don't know the root cause. Is it something mild or something bad? For example, imagine that there were a bug that left MAX_SEQ_NUM_TO_APPLY
in LedgerTxn
between ledgers. Then nodes which were started at different times wouldn't necessarily get the same result. It's probably better to throw.
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 that's a valid point. I removed that fixup commit.
r+ 0e5c9e6 |
Description
Resolves #3365 and #3366.
This PR contains two commits that can be ignored (both prefixed with
TEST REFACTOR - IGNORE
). Once #3362 is merged, these commits can be deleted.Checklist
clang-format
v8.0.0 (viamake format
or the Visual Studio extension)