-
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
feat(app): add upgrade handlers #1121
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1121 +/- ##
==========================================
- Coverage 69.52% 69.36% -0.16%
==========================================
Files 218 219 +1
Lines 22578 22735 +157
==========================================
+ Hits 15697 15771 +74
- Misses 5527 5597 +70
- Partials 1354 1367 +13
Flags with carried forward coverage won't be shown. Click here to find out 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.
This is looking good. A few requested changes. I think separating the tests for manual operations would be nice so that we are not only testing mainnet and the tests in core_test.go
would test a scenario with no matching chain id. Would be easier to add cases for manual operations that are not being tested at the moment and to do so specific to each chain.
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.
why don't we take a complete new account for recovering funds? In that way, we can just replace old account address, pubkey with new one in the account state and bank state
…-network/regen-ledger into aleem/980-upgrade-handlers
Co-authored-by: Ryan Christoffersen <[email protected]>
…-network/regen-ledger into aleem/980-upgrade-handlers
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 looks great. I was think that the tests in patch_test.go
wouldn't need to set up and run the state migrations (not including the manual operations) and then they would only include testing the manual operations but how you set them up works too and is more thorough so I think we should keep it as is.
Items remaining in this pull request:
- consolidate into one upgrade handler
Items remaining that we can address in a followup pull request:
- update community member address (we need an address that does not yet exist on chain)
- add reference ids and update reference ids and issuance dates for any new batches created
app/stable_appconfig.go
Outdated
// address that the community member has access to | ||
const newAddr = "regen14tpuqrwf95evu3ejm9z7dn20ttcyzqy3jjpfv4" |
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.
As discussed on our call, this account has an existing balance and we need an address that does not have a balance and does not exist yet on chain so that we can create a vesting account for the address.
balances:
- amount: "1504879"
denom: uregen
pagination:
next_key: null
total: "0"
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.
Following up on this... @ryanchristo and I just spent some time reviewing this PR in more detail (in particular the recoverFunds()
implementation), and I think this may work as desired even if the user has a pre-existing balance.
The error when setting a periodic vesting account on a pre-existing account only happens in the message server for CreateVestingAccount()
.
So I think the way we are doing it (by ensuring that the vesting acc balance is added to the pre-existing new account balance), and then calling accountKeeper.SetAccount()
should avoid an issues.
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.
See #1121 (comment) and reply.
// project location -> reference-id | ||
// FR -> "" // TODO: add reference-id | ||
// US -> "" | ||
// AU-NSW 2453 -> "" | ||
// K -> "" | ||
// US-FL 9876 -> "" |
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.
Same as above. Will check with @S4mmyb on reference id for projects created on redwood.
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.
My guess is that we can leave reference ID blank on redwood.
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.
Sam is checking with the interface team. They may want some of these projects to have a reference id but we can handle in a followup.
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.
Added this as a followup to the issue so that we are not beta blocking: #980
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.
We can move forward without including any sort of reference id for projects on redwood @ryanchristo
Co-authored-by: Ryan Christoffersen <[email protected]>
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.
Successfully tested software upgrade without chain id regen-1
or regen-redwood-1
. Will need to do more thorough testing using existing mainnet state and redwood state but this looks good to me and the remaining items can be addressed in a followup.
Also, one issue came up but unrelated to the changes here, which is issuer
was not populated in the new credit batch following migrations (opened #1138).
x/ecocredit/migrations/v3/patch.go
Outdated
locationToReferenceIdMap["CD-MN"] = "" | ||
locationToReferenceIdMap["KE"] = "" |
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.
locationToReferenceIdMap["CD-MN"] = "" | |
locationToReferenceIdMap["KE"] = "" | |
locationToReferenceIdMap["CD-MN"] = "VCS-934" | |
locationToReferenceIdMap["KE"] = "VCS-612" |
@S4mmyb what do you think of this for the mai ndombw and kasigao reference ID's?
- Mai Ndombe: VCS-934 (https://registry.regen.network/projects/mai-ndombe)
- Kasigao: VCS-612 (https://registry.regen.network/projects/kasigau)
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.
Committing this change and merging this pull request so that we can tag a beta and test. If we need to make any revisions, we can do so at a later point in time. Updated the issue and added followups: #980
Co-authored-by: Cory <[email protected]>
Co-authored-by: Cory <[email protected]>
Co-authored-by: Cory <[email protected]>
Co-authored-by: Cory <[email protected]>
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, couple of notes for your consideration.
va, ok := lostAccount.(*vestingtypes.PeriodicVestingAccount) | ||
if !ok { | ||
return fmt.Errorf("%s is not a vesting account", lostAddr) | ||
} | ||
|
||
vestingPeriods := va.VestingPeriods | ||
// unlock vesting tokens | ||
newVestingPeriods := make([]vestingtypes.Period, len(va.VestingPeriods)) | ||
for i, vp := range va.VestingPeriods { | ||
vp.Length = 0 | ||
newVestingPeriods[i] = vp | ||
} | ||
va.VestingPeriods = newVestingPeriods | ||
ak.SetAccount(ctx, va) | ||
|
||
// send spendable balance from lost account to new account | ||
spendable := bk.SpendableCoins(ctx, lostAccount.GetAddress()) | ||
if err := bk.SendCoins(ctx, lostAccount.GetAddress(), newAccount.GetAddress(), spendable); err != nil { | ||
return err | ||
} | ||
|
||
newPVA := vestingtypes.NewPeriodicVestingAccount( | ||
authtypes.NewBaseAccount(newAccount.GetAddress(), newAccount.GetPubKey(), newAccount.GetAccountNumber(), newAccount.GetSequence()), | ||
va.OriginalVesting, va.StartTime, vestingPeriods, | ||
) | ||
ak.SetAccount(ctx, newPVA) |
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 works all fine but looks complex for me. I was advising to consider a brand new account from user for simplicity. The solution can simply be
// read lost-account from auth store
acc := regenApp.AccountKeeper.GetAccount(ctx, lostAddr)
newAcc := acc;
newAcc.Address = newAddr
newAcc.Pubkey = nil
// delete old account
err := regenApp.AccountKeeper. RemoveAccount(ctx, lostAcc)
// set new account
err := regenApp.AccountKeeper.SetAccount(ctx, newAcc)
similarly for bank balances too. Not sure how this sounds for others but I am comfortable with this approach.
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.
Yea, this would be easier.
Given the community member is not necessarily an experience blockchain user and knowing the address provided is something they have access to, I think the extra work on our end is ok. I'm going to merge as is so that we can cut a beta and start more thorough testing but I added this as a potential followup to the issue: #980
Very nice work @aleem1314 🚀 |
Description
Ref: #980
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 changeCHANGELOG.md
Reviewers 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