When you don’t understand, just abstain from voting…
2 Likes
awesome news
Got it. Thanks for the answer. Could we get some insight on why this issue didn’t show up in earlier testing that was done? We’re looking to get insight on where any gaps in testing for releases may currently exist.
My answer is yes and I support all your suggestions and the Lunaclassic group to improve the situation of Lunaclassic and the Lunaclassic community. Thank you for all your hard work.
Hi Ed,
Thank you for the detailed proposal.
I have some questions about the state breaking changes?
Questions:
- do our smart contracts have to be reuploaded?
- for cw721 contracts, all state will be lost?
- for cw20 contracts, all amounts will be lost?
1 Like
Sorry for the delay. This was our update test script. core/upgrade-test.sh at main · classic-terra/core · GitHub
And everything passed the test. Everything also worked fine on testnet, and on a full node running on mainnet. This is when we posted the first edition of v1.0.5. There was no problem with the v1.0.5
Then I decided to do a full simulation of the upgrade to v2.0.4 (our next upgrade). This is when I caught the issue. The code that was supposed to trigger and load the module states into memory never got triggered. It was triggered in our original test because the state was loaded from genesis. Ultimately, we decided to trigger the module code at a certain block height in order to get it to run. This enables us to proceed with the v2 upgrade.
6 Likes
@ek826 well done Ed thank you for the update. Ignore the fudders trying to tear the L1 team and LUNC apart. Keep up the good work. Many quiet people support you.
1 Like
Underrated post. Great explanation about governance.
1 Like
The contract doesn’t account for the seven terabytes of state that are already here. Any historical state can cause issues in an upgrade. What this is testing is can a blank chain with no history be upgraded from 1.0.4 to 1.0.5. It does nothing else and does not resemble the real world.