-
Notifications
You must be signed in to change notification settings - Fork 490
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: remove redundant method LookupAccountDataByAddress #5216
cleanup: remove redundant method LookupAccountDataByAddress #5216
Conversation
Codecov Report
@@ Coverage Diff @@
## master #5216 +/- ##
==========================================
- Coverage 53.56% 53.55% -0.02%
==========================================
Files 441 441
Lines 55098 55079 -19
==========================================
- Hits 29515 29497 -18
+ Misses 23298 23292 -6
- Partials 2285 2290 +5
... and 8 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. 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.
LGTM - easy to follow thinking, clean.
switch err { | ||
case nil: | ||
if len(acctDataBuf) > 0 { | ||
persistedAcctData := &trackerdb.PersistedAccountData{Addr: addr, Ref: ref} |
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 is still a difference. this code does not set Round
but LookupAccount
does set. I did not check if this is important or not, but I suggest to either check or clear it here
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.
The Round
is the round of the db at the point the "old value" was read.
The old code wasn't setting it because it wasn't querying it, since it didn't seem to care about what round the old value was from. LookupAccount
reads the round, because it's part of the data structure being read, and it might not be used by this caller, but it is used by others.
This can't possible break code, because if any code was attempting to get meaning from the Round
field in this "old value" entries, they all had Round(0)
, implying that all this old values were read at genesis, which is flat out wrong.
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.
a problem could be in a code that uses Round=0
as some indication similarly to rowid=0
. I'm pretty sure there is no such code, but have you checked? The PR description claimed the code is equivalent but it is not for this case and for the empty data as discussed in a thread below.
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.
Hello, isn't the account data hashed by the catchpoint tracker, so wouldn't populating it with a new nonzero round number change that hash?
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 are right Round might affect MT hash but we've checked all possible code paths and returning Round=0 not possible now.
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.
Catchpoint tracker's AccountHashBuilderV6 uses the BaseAccountData.UpdateRound value, the round number of the change to this account. This is not the same thing as the PersistedAccountData.Round value which is the current round that the DB was synced up to at the time of the SQL query lookup.
I think we need a test confirming the |
Ignacio and Pavel to follow up |
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.
Agreed with Pavel as we both can recall subtle unexpected changes to resourcesLoadOld and accountsLoadOld leading to serious bugs before, this PR would feel safer if it either (1) exactly matched what the behavior of old code paths it is replacing does, or (2) had some kind of test to show the 3 different cases it is merging into 1 have the same impact to commitRound.
I reexamined code paths and it appears even an empty/nil accounts in It might cause a problem with transferring to an empty account since the new code would assume there is no such account and transfer cannot be recorded. The PR to clean up possible empty accounts appears to be a fix. |
Here is a demo making an empty account and transferring to it. DB will fail to commit b/c of unique constraint error master...algorandskiy:go-algorand:pavel/empty-acct-test-demo |
Here is a demo making an empty account and transferring to it. DB will fail to commit b/c of unique constraint error master...algorandskiy:go-algorand:pavel/empty-acct-test-demo
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.
Please change the address logging %v -> %s - we use canonical string addresses almost everywhere outside the code.
LGTM. The reason why I approve this is the resources migration converted all possible old empty/nil accounts, and no such records should be in the DB (that existed at the very early days).
0a0e779
to
2a65b33
Compare
@cce please take another look. |
// unexpected error - let the caller know that we couldn't complete the operation. | ||
return err | ||
} | ||
// update the account | ||
a.updateOld(idx, data) |
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.
The only remaining change I see between the old code and this new version is that we didn't use to fill in oldAcct.Round (the PersistedAccountData.Round field) and now we are filling it in with the Round of the oldAcct.
Before the old code would only fill in Addr, Ref, and AccountData but Round was not available from the old LookupAccountDataByAddress query so was not set for oldAcct.
I can't find anywhere where oldAcct.Round is used though ... oldAcct is being used for Ref (to set on newAcct's Ref) and in the onlineAccountsNewRoundImpl there is a check for oldAcct.AccountData != newAcct
but Round does not seem used.
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.
Agreed, old Round is not used anywhere
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.
After clearing up the comments and adding the extra err return case to LookupAccount ... the only remaining change I see between the old code and this new version is that we didn't used to fill in oldAcct.Round (the PersistedAccountData.Round field) and now we are filling it in with the Round of the oldAcct (the old code would only fill in Addr, Ref, and AccountData).
I can't find anywhere where oldAcct.Round is used though ... oldAcct is being used for Ref (to set on newAcct's Ref) and in the onlineAccountsNewRoundImpl there is a check for oldAcct.AccountData != newAcct but Round does not seem used.
related: unneeded PR #5267
You mean MT deleting here, right?
|
confirmed that newAcct/oldAcct hashing is using BaseOnlineAccountData part of PersistedOnlineAccountData and not the round. |
Summary
LookupAccountDataByAddress
was only used in one place and was repeating the same logic as inLookupAccount
.The difference between the two was that
LookupAccountDataByAddress
returned raw bytes instead of decoding the account data.LookupAccountDataByAddress
was removed from the interface and the call site was changed to usedLookupAccount
instead.Test Plan
Existing tests.