-
Notifications
You must be signed in to change notification settings - Fork 320
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
pd: add no-op migration for APP_VERSION 10 #5074
Conversation
The no-op migration is necessary but not yet sufficient: I am indeed encountering the version mismatch logic anticipated in #5073 (comment). Working with a pre-upgrade backup of node state to test changes, will append a patch here and mark RFR when done. |
Follow-up to #5073, which should have included a no-op migration.
b254713
to
1e7537e
Compare
In the first draft of this PR, I'd neglected to update the default migration used by |
## Describe your changes Follow-up to #5073, which should have included a no-op migration. ## Issue ticket number and link Towards #5010. ## Testing and review This work will be used to perform a chain upgrade on the PL testnet. Once that's done, we should expect CI to pass fully on this PR, in particular the "testnet-integration" suite. ## Checklist before requesting a review - [x] I have added guiding text to explain how a reviewer should test these changes. - [x] If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: > provides migration logic for proposed protocol-breaking changes
## Describe your changes Follow-up to #5073, which should have included a no-op migration. ## Issue ticket number and link Towards #5010. ## Testing and review This work will be used to perform a chain upgrade on the PL testnet. Once that's done, we should expect CI to pass fully on this PR, in particular the "testnet-integration" suite. ## Checklist before requesting a review - [x] I have added guiding text to explain how a reviewer should test these changes. - [x] If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: > provides migration logic for proposed protocol-breaking changes
## Describe your changes Follow-up to #5073, which should have included a no-op migration. ## Issue ticket number and link Towards #5010. ## Testing and review This work will be used to perform a chain upgrade on the PL testnet. Once that's done, we should expect CI to pass fully on this PR, in particular the "testnet-integration" suite. ## Checklist before requesting a review - [x] I have added guiding text to explain how a reviewer should test these changes. - [x] If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: > provides migration logic for proposed protocol-breaking changes
Describe your changes
Follow-up to #5073, which should have included a no-op migration.
Issue ticket number and link
Towards #5010.
Testing and review
This work will be used to perform a chain upgrade on the PL testnet. Once that's done, we should expect CI to pass fully on this PR, in particular the "testnet-integration" suite.
Checklist before requesting a review
I have added guiding text to explain how a reviewer should test these changes.
If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: