[Bug]: Unexpected gas prices behaviour when one of multiple gas prices is zero

[migueldingli1997]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

The SDK lets us specify multiple gas prices, to give users the option to pay in one gas price or another. If one of multiple gas prices is set to zero, the assumption here is that the same reasoning applies, and the user will be able to either pay zero in the zeroed gas price, or a non-zero in any of the other gas prices.

For example: 0.025uatom,0uxyz - I expect to be able to pay zero uxyz or a non-zero amount of uatom.

What ends up happening because of the way that the gas price is parsed is that the zero coin gets removed by the sanitization applied by ParseDecCoins. This leaves us with just the non-zero token, and thus no option to not pay a fee.

Cosmos SDK Version

main

How to reproduce?

Set gas prices to any two unique tokens, one of which is zero.

[alexanderbez]

Zero coins aren't valid. 0.025uatom,0uxyz isn't a valid expression. 0.025uatom is. Meaning you must may that gas price or higher.

[migueldingli1997]

I understand, thanks. I just want to point out that as a user this was unexpected behaviour. I can also imagine that there is not a lot of use-cases for setting one of the gas prices to zero.

[alexanderbez]

Can I ask why you think this is unexpected behavior?

If I proceed, for example, to use a mobile money transfer app, and that app requires a fee to use their service, the app wouldn't say "give us zero or more of this". It would either be free or it wouldn't. Similarly, it doesn't make sense to have "zero" of something. You either have it or you don't.

In the context of fees, your use case is totally valid, but that's just not the expression you'd use to describe it. Instead, what you'd say is just 0.0025uatom then your fee handler checks if fees are present (if they're not consider it a free tx) and if there are fees attached, you just check the value against the minimum.

[migueldingli1997]

Yeah I guess this can be handled from the application side, perhaps by overriding the DeductFeeDecorator if this behaviour is really required. Thanks for considering it and presenting your reasoning.