Skip to content
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

Simplify Migration Structs #1036

Merged
merged 11 commits into from
Sep 30, 2024
Merged

Simplify Migration Structs #1036

merged 11 commits into from
Sep 30, 2024

Conversation

brennanjl
Copy link
Collaborator

@brennanjl brennanjl commented Sep 27, 2024

This PR simplifies migration structs. There are three key changes:

  1. It removes chain-id from the migration proposals, since they are effectively a suggestion anyways.
  2. It simplifies the struct that is passed back from the client when querying for migrations. It previously used to return serialized genesis.json, but now returns a much slimmed down struct that only contains necessary info.
  3. It adds kwild's minor version to the migration metadata when querying a node. This is because we still send the snapshot metadata serialized, and thus need to maintain compatibility between versions. I thought about moving snapshot metadata into core/types, but didn't to keep it simple.

@brennanjl brennanjl changed the title fail on invalid migration config Simplify Migration Structs Sep 27, 2024
@brennanjl
Copy link
Collaborator Author

Have not tested this btw

core/types/types.go Outdated Show resolved Hide resolved
jchappelow
jchappelow previously approved these changes Sep 27, 2024
Copy link
Member

@jchappelow jchappelow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow this feels super clean. Have not tested either and we definitely want @charithabandi to review and test, but LGTM.

@brennanjl
Copy link
Collaborator Author

I'm going to test this over the weekend since it is such a big change

@charithabandi
Copy link
Contributor

Looking into this rn

@jchappelow
Copy link
Member

Regarding CI failure, on the "unhealthy" node1 I see:

2024-09-30 10:30:42 kwild version 0.9.0-pre (Go version go1.23.0)
2024-09-30 10:30:42 Root directory "/app/kwil"
2024-09-30 10:30:42 Private key path: /app/kwil/private_key
2024-09-30 10:30:42 2024-09-30T15:30:42.811Z    info    kwild   version 0.9.0-pre commit 
2024-09-30 10:30:42 2024-09-30T15:30:42.811Z    info    kwild   Entering migration mode {"migrate_from": "http://01d8aa26-5e5f-4756-95af-a6c614fb0aa2-node1-1:8484"}
2024-09-30 10:30:42 2024-09-30T15:30:42.818Z    info    kwild   Requesting genesis state from the old chain     {"listen_address": "http://01d8aa26-5e5f-4756-95af-a6c614fb0aa2-node1-1:8484"}
2024-09-30 10:30:42 2024-09-30T15:30:42.822Z    info    kwild   Genesis state not available     {"error": "status NoActiveMigration", "retry after(sec)": 30}

So it never gets healthy, at least not in 30 sec

@brennanjl
Copy link
Collaborator Author

Yeah we got it sorted, it was really really stupid.

I realized I was testing with a binary that was built from main, not this branch 🤦 . As soon as I tested with this branch I saw the error

@brennanjl
Copy link
Collaborator Author

Ok just finished testing this. I feel good about it

logger.Info("Genesis state already downloaded", log.String("genesis snapshot", snapshotFileName))

if !validateGenesisState(snapshotFileName, genesisCfg.DataAppHash) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

validateGenesisState could use an update. I don't think it should itself call failBuild (it's not in build.go and PrepareForMigration can return errors without having to panic). Also, a bunch of logic there is obsoleted now that we're ensuring it's existence here. The empty apphash logic in validateGenesisState is also a little questionable given the current changes, plus the bytes.Equal in the final return covers the length an nilness checks implicitly.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh yeah. Im just going to change this whole function since it is a bit convoluted in its usage

var res display.TxHashResponse
err := o.runCommand(ctx, &res, "migrate", "propose", activationHeight.String(), migrationDuration.String(), chainID)
err := o.runCommand(ctx, &res, "migrate", "propose", "activation-period", activationHeight.String(), "duration", migrationDuration.String())
Copy link
Member

@jchappelow jchappelow Sep 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't need -- on activation-period and duration?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh whoops. Currently we do not test the cli for this, but yes you are correct

@brennanjl
Copy link
Collaborator Author

Is this good to go? @charithabandi @jchappelow

@jchappelow
Copy link
Member

I am doing staging e2e this evening, but can merge. Any issues can be resolved after

@brennanjl
Copy link
Collaborator Author

Cool, thanks. Trying to get it merged b/c I know there will be merge conflicts with #1040

@brennanjl brennanjl merged commit 1494744 into main Sep 30, 2024
2 checks passed
@brennanjl brennanjl deleted the fail-migration-cfg branch September 30, 2024 22:08
@jchappelow
Copy link
Member

Cool, thanks. Trying to get it merged b/c I know there will be merge conflicts with #1040

They're minimal (I've resolved locally), but that's true

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants