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

Consider moving BlockedParams to paramfilter #3038

Closed
rootulp opened this issue Jan 24, 2024 · 3 comments
Closed

Consider moving BlockedParams to paramfilter #3038

rootulp opened this issue Jan 24, 2024 · 3 comments
Labels
good first issue Good for newcomers ice-box this label is automatically applied to all issues. it is removed after starting work refactor optional label for items that are related to implementation work and do not change functionality warn:api breaking item will be break an API and require a major bump

Comments

@rootulp
Copy link
Collaborator

rootulp commented Jan 24, 2024

nice, if we're going to add the tests here, then we might want to move the actually params to block here as well. super duper optional tho

Originally posted by @evan-forbes in #3007 (review)

@rootulp
Copy link
Collaborator Author

rootulp commented Jan 24, 2024

@evan-forbes is the proposal to move

celestia-app/app/app.go

Lines 733 to 746 in cd0a1cd

// BlockedParams are params that require a hardfork to change, and cannot be changed via
// governance.
func (*App) BlockedParams() [][2]string {
return [][2]string{
// bank.SendEnabled
{banktypes.ModuleName, string(banktypes.KeySendEnabled)},
// staking.UnbondingTime
{stakingtypes.ModuleName, string(stakingtypes.KeyUnbondingTime)},
// staking.BondDenom
{stakingtypes.ModuleName, string(stakingtypes.KeyBondDenom)},
// consensus.validator.PubKeyTypes
{baseapp.Paramspace, string(baseapp.ParamStoreKeyValidatorParams)},
}
}
from the app package to the paramfilter package? I think that's API breaking but do-able.

@rootulp rootulp changed the title Consider moving params to block Consider moving BlockedParams to paramfilter Jan 24, 2024
@evan-forbes evan-forbes added warn:api breaking item will be break an API and require a major bump refactor optional label for items that are related to implementation work and do not change functionality good first issue Good for newcomers ice-box this label is automatically applied to all issues. it is removed after starting work and removed needs:triage labels Mar 11, 2024
@evan-forbes
Copy link
Member

yeah, I think that would close this issue. I'm still of the opinion that its super optional. I don't see that much benefit either way.

we could explore other refactors as well. in the context of versioning and migrations, there might be a small benefit to moving the module. It could also make it worse if we have to import a bunch of modules with their own go mods there just to name them

@rootulp
Copy link
Collaborator Author

rootulp commented May 16, 2024

kk if super optional, let's close as won't do for now. Please reopen if there's a compelling reason to do this

@rootulp rootulp closed this as not planned Won't fix, can't repro, duplicate, stale May 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers ice-box this label is automatically applied to all issues. it is removed after starting work refactor optional label for items that are related to implementation work and do not change functionality warn:api breaking item will be break an API and require a major bump
Projects
None yet
Development

No branches or pull requests

2 participants