Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
refactor(golang/cosmos): Simplify and DRY out isPrimaryUpgradeName #10091
base: master
Are you sure you want to change the base?
refactor(golang/cosmos): Simplify and DRY out isPrimaryUpgradeName #10091
Changes from all commits
8b9e834
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While no longer in use right now, this helper was extremely useful when we had to generate different core proposal configs depending on the upgrade name (different price feed depending on the network). Let keep it around.
Maybe restore the check that
name
is a valid upgrade name inisPrimaryUpgradeName
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isPrimaryUpgradeName
already includes that check... if the provided name is not a valid upgrade name, thenisPrimary, found := upgradeNamesOfThisVersion[name]
will set bothisPrimary
andfound
to false, the latter resulting in a panic two lines down. And any non-panicky validity check could be trivially performed againstupgradeNamesOfThisVersion
in exactly the same way.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I'm asking here is to keep
validUpgradeName
around as it was useful for a switch case that we needed when conditionally generating core proposals. I figured calling it fromisPrimaryUpgradeName
was an easy way to keep it in use to satisfy golint checks.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you point to that switch case? I think I'd also like it better without
validUpgradeName
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to do some git blaming to track the refactor that introduced it, but the concept was first introduced here:
agoric-sdk/golang/cosmos/app/upgrade.go
Line 37 in ab43404
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, for such a release I'd probably just generalize
upgradeNamesOfThisVersion
frommap[string]bool
tomap[string][]string
(with each value containing the correct oracle addresses). And if we want that kind of generalization to be obvious, I can update this PR frommap[string]bool
tomap[string]*upgradeMetaData
(where the basic upgradeMetaData is juststruct{ isPrimary bool }
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the concern with keeping part of the customization related to upgrade-name imperative instead of through configuration? In JS a
switch
case is perfectly acceptable to do this. The problem is that in golang we don't have types to help us check a typo wasn't made.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It requires the upgrade names to be retyped and muddies their source of truth, creating another opportunity for error in release branch initialization (which in fact I did miss in #10088). And it's not actually imperative anyway, since that link demonstrates that there was in fact a static mapping from upgrade name to data that was serialized into a JSON template. Basically, it's unnecessary complexity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that particular case there was only a config change indeed. I would like a flexible option that allows conditionally including some core proposals depending on the upgrade name. What do you suggest is the most robust approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest generalizing
upgradeNamesOfThisVersion
: