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

Remove duplicate fork definitions #3304

Merged
merged 9 commits into from
Aug 16, 2024
Merged

Conversation

StephenButtolph
Copy link
Contributor

@StephenButtolph StephenButtolph commented Aug 15, 2024

Why this should be merged

type fork uint8 seems to be very popular... Moving this into a common package and sharing where possible.

How this works

Adds an upgradetest package and exposes common functionality that existing VMs re-implement multiple times.

How this was tested

  • CI

@@ -42,14 +40,7 @@ import (
keystoreutils "github.com/ava-labs/avalanchego/vms/components/keystore"
)

type fork uint8
Copy link
Contributor Author

Choose a reason for hiding this comment

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

1

@@ -97,8 +88,6 @@ func init() {
}
}

type fork uint8
Copy link
Contributor Author

Choose a reason for hiding this comment

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

2

@@ -100,8 +93,6 @@ func init() {

type stakerStatus uint

type fork uint8
Copy link
Contributor Author

Choose a reason for hiding this comment

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

3

@@ -90,8 +83,6 @@ func init() {
}
}

type fork uint8
Copy link
Contributor Author

Choose a reason for hiding this comment

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

4

@@ -162,8 +150,6 @@ func init() {
}
}

type fork uint8
Copy link
Contributor Author

Choose a reason for hiding this comment

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

5

@StephenButtolph StephenButtolph self-assigned this Aug 16, 2024
@StephenButtolph StephenButtolph added testing This primarily focuses on testing cleanup Code quality improvement labels Aug 16, 2024
@StephenButtolph StephenButtolph added this to the v1.11.11 milestone Aug 16, 2024
@StephenButtolph StephenButtolph marked this pull request as ready for review August 16, 2024 02:52

// SetConfigTimesTo sets the upgrade time of the provided fork, and all prior
// forks, to the provided upgradeTime.
func SetConfigTimesTo(c *upgrade.Config, fork Fork, upgradeTime time.Time) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The signature looks like this to align with a pointer receiver method on the Config type (which can't be done here because this is a testing package)

Copy link
Contributor

@ARR4N ARR4N left a comment

Choose a reason for hiding this comment

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

I'm concerned that the philosophers will now die of starvation.

All questioning comments are for my own learning.

// SetTimesTo sets the upgrade time of the provided fork, and all prior forks,
// to the provided upgradeTime.
func SetTimesTo(c *upgrade.Config, fork Fork, upgradeTime time.Time) {
switch fork {
Copy link
Contributor

Choose a reason for hiding this comment

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

Elegant 😍

vms/platformvm/block/builder/helpers_test.go Show resolved Hide resolved
UpgradeConfig: upgrade.Config{
BanffTime: mockable.MaxTime, // banff is not activated
},
UpgradeConfig: upgradetest.GetConfig(upgradetest.ApricotPhasePost6),
Copy link
Contributor

Choose a reason for hiding this comment

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

I really like this pattern. It's much more declarative around intent / effect.

ApricotPhase4MinPChainHeight: 0,
DurangoTime: mockable.MaxTime,
},
Upgrades: upgradetest.GetConfigWithUpgradeTime(upgradetest.ApricotPhase4, time.Time{}),
Copy link
Contributor

Choose a reason for hiding this comment

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

Does the (Go) zero-value time.Time{} have a special meaning?

And the Unix zero-value? Is this effectively the same as using upgrade.InitiallyActiveTime?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These values seem to be depended on in the tests that use this code... I'm hoping that we can remove the reliance on time.Time{} and time.Unix(0, 0) as we continue to fix these tests... But it felt out of scope for this PR...

TL;DR: I don't know... Changing them breaks the tests... The tests should be improved in a later PR.

// be unscheduled.
func GetConfigWithUpgradeTime(fork Fork, upgradeTime time.Time) upgrade.Config {
c := upgrade.Config{
ApricotPhase4MinPChainHeight: 0,
Copy link
Contributor

Choose a reason for hiding this comment

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

this is the zero value so why explicitly set it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could remove this - I felt like it was a useful shout-out... But I'm fine deleting it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

removed.

ApricotPhase4MinPChainHeight: 0,
DurangoTime: time.Unix(0, 0),
},
Upgrades: upgradetest.GetConfigWithUpgradeTime(upgradetest.Latest, time.Unix(0, 0)),
Copy link
Contributor

Choose a reason for hiding this comment

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

I know it's no the same, as one is 1970 and the other is just 0, but, why the discrepancy between time.Unix(0,0) and time.Time? Won't this test work with time.Time{} ?

Copy link
Contributor

Choose a reason for hiding this comment

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

i mean - maybe it's better to be consistent?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did this to keep the same values, but you're right time.Time{} seems to work as well. I switched it to use that for consistency.

@StephenButtolph StephenButtolph added this pull request to the merge queue Aug 16, 2024
@StephenButtolph StephenButtolph removed this pull request from the merge queue due to a manual request Aug 16, 2024
@StephenButtolph StephenButtolph added this pull request to the merge queue Aug 16, 2024
Merged via the queue into master with commit 4b4ec8a Aug 16, 2024
21 checks passed
@StephenButtolph StephenButtolph deleted the remove-duplicate-code branch August 16, 2024 15:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup Code quality improvement testing This primarily focuses on testing
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

4 participants