modify pool-incentives submit proposal cli

[catShaark]

Closes: #1888

Brief Changelog

• add proposal-specific flags to NewCmdSubmitUpdatePoolIncentivesProposal and NewCmdSubmitReplacePoolIncentivesProposal
• disable poolincetives tx commands since these should be only used with a gov prefix
• register NewCmdSubmitReplacePoolIncentivesProposal handler on the gov module

Testing and Verifying

• Manually verified

Documentation and Release Note

• Does this pull request introduce a new feature or user-facing behavior changes? yes
• Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? yes
• How is the feature or change documented? not documented

[ValarDragon]

ooof, would this be state breaking to backport? (I don't have a sense for where ProposalType gets used)

[catShaark]

I think they're used in routing

[alexanderbez]

This is used in x/gov routing when executing the proposal's handler.

[mattverse]

If it's only used for routing, I assume it's not going to be state-breaking to backport?

[catShaark]

I think If we have a ProposalTypeReplacePoolIncentives submited, this will be state-breaking

[p0mvn]

LGTM - I think we should create a changelog entry for this

[mattverse]

If it's only used for routing, I assume it's not going to be state-breaking to backport?

[mattverse]

hrmm is it safe to delete this / is there a reason behind deleting this?

[catShaark]

It is decided in #1888 that submit proposal cmd should only have gov prefix, so these command will be registered with gov handler instead of tx cmd of incentives module.

[catShaark]

LGTM - I think we should create a changelog entry for this

Should I add this to state breaking entry or not

[mattverse]

imo should go under breaking changes

[ValarDragon]

Sorry, I'm actually generally confused about whats going on in these governance proposal routing.

My understanding is that in the today code, replace incentives proposal works on mainnet. Looking into this, looks like the handler is registered here? https://github.com/osmosis-labs/osmosis/blob/main/app/keepers/keepers.go#L366

Which then splits execution based on type

osmosis/x/pool-incentives/handler.go

Lines 12 to 24 in fd23552

	func NewPoolIncentivesProposalHandler(k keeper.Keeper) govtypes.Handler {
	return func(ctx sdk.Context, content govtypes.Content) error {
	switch c := content.(type) {
	case *types.UpdatePoolIncentivesProposal:
	return handleUpdatePoolIncentivesProposal(ctx, k, c)
	case *types.ReplacePoolIncentivesProposal:
	return handleReplacePoolIncentivesProposal(ctx, k, c)
	default:
	return sdkerrors.Wrapf(sdkerrors.ErrUnknownRequest, "unrecognized pool incentives proposal content type: %T", c)
	}
	}
	}

So the routes being equivalent may be correct?

[ValarDragon]

(this is also needlessly complex, and we should simplify it)

[p0mvn]

Sorry, I'm actually generally confused about whats going on in these governance proposal routing.

My understanding is that in the today code, replace incentives proposal works on mainnet. Looking into this, looks like the handler is registered here? https://github.com/osmosis-labs/osmosis/blob/main/app/keepers/keepers.go#L366

Which then splits execution based on type

osmosis/x/pool-incentives/handler.go

Lines 12 to 24 in fd23552

	func NewPoolIncentivesProposalHandler(k keeper.Keeper) govtypes.Handler {
	return func(ctx sdk.Context, content govtypes.Content) error {
	switch c := content.(type) {
	case *types.UpdatePoolIncentivesProposal:
	return handleUpdatePoolIncentivesProposal(ctx, k, c)
	case *types.ReplacePoolIncentivesProposal:
	return handleReplacePoolIncentivesProposal(ctx, k, c)
	default:
	return sdkerrors.Wrapf(sdkerrors.ErrUnknownRequest, "unrecognized pool incentives proposal content type: %T", c)
	}
	}
	}

So the routes being equivalent may be correct?

I think that the linked handler registration is focused on routing. On the other hand, this PR is primarily about fixing the client bootstrapping / cli.

Currently, pool-incentives gov cli is broken due to incorrectly setting up the cli logic and registering some flags twice. I've verified that this should help fix the original problem in #1888.

We expose 2 ways to submit pool-incentives proposals:

• osmosisd tx poolincentives update-pool-incentives
• osmosisd tx gov submit-proposal update-pool-incentives

Only the latter is correct because it properly gets registered on the gov module. The original bug is stemming from attempting to support both ways and, as a result, registering some CLI flags twice which breaks both commands.

The change related to the proposal type seems to be a pass-through change. However, It does seem like a valid change that we should keep because we were returning an invalid proposal type.

The claim that ProposalType() is used in routing does seem to be correct. Although this is client-side (rest) routing.

Based on my investigation, the changes in this PR do not affect the state-breaking routing we are concerned about.

I think we need the changes in this PR to fix the CLI and client (REST) routing. However, it might make sense to spend more time manually testing to ensure that everything is sound

[github-actions]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. Thank you!

[p0mvn]

Hi @catShaark . I just would like to confirm that you've gotten a chance to manually test that both pool incentives proposals are functioning as expected.

Please let me know

[p0mvn]

I think it would be great to have an e2e test for submitting these pool-incentive proposals. Would you be interested in adding it?

[p0mvn]

utACK. Changes lgtm.

I would like to know whether a manual test has been done or if there is intention to add an e2e test for this?

Either is fine with me to merge this