Skip to content

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

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

}
}

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


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

}
}

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

}
}

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 😍

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
@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.

5 participants