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

Migration to add keys to service accounts for testing #6969

Merged

Conversation

janezpodhostnik
Copy link
Contributor

@janezpodhostnik janezpodhostnik commented Feb 4, 2025

I changed the Add key migration (originally added here: #6926) so that the code can be committed to master, but it is not runnable without changing this constant IAmSureIWantToRunThisMigration. If you change it the test will start failing which would then prevent you from accidentally merging that branch.

see: #6970

@codecov-commenter
Copy link

codecov-commenter commented Feb 4, 2025

Codecov Report

Attention: Patch coverage is 0.29851% with 334 lines in your changes missing coverage. Please review.

Project coverage is 41.09%. Comparing base (f0d7ec9) to head (65c285c).

Files with missing lines Patch % Lines
cmd/util/ledger/migrations/add_key_migration.go 0.00% 307 Missing ⚠️
...execution-state-extract/execution_state_extract.go 0.00% 25 Missing ⚠️
cmd/util/cmd/execution-state-extract/cmd.go 33.33% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #6969      +/-   ##
==========================================
- Coverage   43.29%   41.09%   -2.20%     
==========================================
  Files        1558     2130     +572     
  Lines      139443   186669   +47226     
==========================================
+ Hits        60366    76719   +16353     
- Misses      74026   103524   +29498     
- Partials     5051     6426    +1375     
Flag Coverage Δ
unittests 41.09% <0.29%> (-2.20%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@@ -422,6 +422,8 @@ func run(*cobra.Command, []string) {
var migs []migrations.NamedMigration

switch flagMigration {
case "add-keys":
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
case "add-keys":
case "add-migrationnetwork-keys":

maybe making the purpose a bit more clear and specific.

}

// add key to node accounts
for _, nodeAddress := range mainnetNodeAddresses {
Copy link
Member

Choose a reason for hiding this comment

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

As double protection, I would suggest to use a emptyNodeAddresses here. So in order to use it, both emptyNodeAddresses and IAmSureIWantToRunThisMigration have to be updated. Updating only one would only be a no-op.

Suggested change
for _, nodeAddress := range mainnetNodeAddresses {
for _, nodeAddress := range emptyNodeAddresses {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you think these will change over time? wouldn't it be better to just have them prepared here?

Copy link
Member

@zhangchiqing zhangchiqing Feb 5, 2025

Choose a reason for hiding this comment

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

I mean we keep the mainnetNodeAddresses variable, but we create another emptyNodeAddresses variable. And by default the emptyNodeAddresses is used, so that this is a double protection.

Then, in order to use it in migration mainnet, we need to do 2 things:

  1. set IAmSureIWantToRunThisMigration to true
  2. replace emptyNodeAddresses with mainnetNodeAddresses here.

And if we forgot to do step 2, the IHaveReplacedEmptyNodeAddressesToMainnetAddresses is still false, and the error will remind us.

And if we updated IHaveReplacedEmptyNodeAddressesToMainnetAddresses to true, but didn't actually do step 2, then it will still be a no-op.

Does it make sense?

Copy link
Contributor

Choose a reason for hiding this comment

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

what about requiring a specific chainID instead?

I think it's more likely that we accidentally merge code with the updated config so adding a check that we wouldn't need to change would help avoid accidental merges allowing this migration against a main network.

if !IAmSureIWantToRunThisMigration {
panic("Cannot run AddKeyMigration migration")
}

Copy link
Member

Choose a reason for hiding this comment

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

Better to add another "checkbox" to remind the required step:

Suggested change
if !IHaveReplacedEmptyNodeAddressesToMainnetAddresses {
panic("didn't use the mainnet node addreses")
}

reporter reporters.ReportWriter
}

var _ AccountBasedMigration = &AddKeyMigration{}
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
var _ AccountBasedMigration = &AddKeyMigration{}
var _ AccountBasedMigration = (*AddKeyMigration)(nil)

// This migration is not safe to run on actual networks.
// It is used for getting control over system accounts so that they can be tested
// in a copied environment. When we need to do this it is best to create a branch
// where this variable is set to true, and use that temporary branc to run migrations.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
// where this variable is set to true, and use that temporary branc to run migrations.
// where this variable is set to true, and use that temporary branch to run migrations.

}

// add key to node accounts
for _, nodeAddress := range mainnetNodeAddresses {
Copy link
Contributor

Choose a reason for hiding this comment

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

what about requiring a specific chainID instead?

I think it's more likely that we accidentally merge code with the updated config so adding a check that we wouldn't need to change would help avoid accidental merges allowing this migration against a main network.

@janezpodhostnik janezpodhostnik added this pull request to the merge queue Feb 6, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to no response for status checks Feb 6, 2025
@j1010001 j1010001 enabled auto-merge February 6, 2025 19:00
@j1010001 j1010001 added this pull request to the merge queue Feb 6, 2025
Merged via the queue into master with commit 4ce667d Feb 6, 2025
56 checks passed
@j1010001 j1010001 deleted the janez/migration-mainnet-add-keys-to-core-contracts-master branch February 6, 2025 19:26
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.

6 participants