apply_authorized_upgrade: Implement feeless_if

[bkchr]

This pr implements the feeless_if feature for apply_authorized_upgrade. The call would be feeless if the given code is authorized.

Besides that the pr is doing some clean ups.

[bkchr]

/cmd prdoc --audience runtime_user --bump major

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/13686410325
Failed job name: run-frame-omni-bencher

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/13686410367
Failed job name: test-linux-stable-runtime-benchmarks

[bkontur]

Nice! Finally, a real usage example. I will also adjust my PR accordingly.

But iiuc, feeless_if won't work unless we add SkipCheckIfFeeless and pallet_skip_feeless_payment to the runtimes, right? Please see my related questions here: #7592 (comment).

So, iiuc, feeless_if won't have any effect without SkipCheckIfFeeless, but in this case, execution will still be free because of pays_fee: Pays::No, correct?

Next, if we add SkipCheckIfFeeless and pallet_skip_feeless_payment, and we change DispatchResultWithPostInfo to DispatchResult, then we no longer need the PostDispatchInfo { pays_fee: Pays::No, ... } code, right? (Probably because of prevent further transactions we want to keep it as it is here)

And lastly, when we make feeless_if + SkipCheckIfFeeless work with TransactionExtensions, how does it behave in the case of an extrinsic error? For example, if feeless_if passes and returns true, but fn apply_authorized_upgrade(..) fails on Self::can_set_code(..), will the user still be charged, or will it remain free?

[gui1117]

But iiuc, feeless_if won't work unless we add SkipCheckIfFeeless and pallet_skip_feeless_payment to the runtimes, right? Please see my related questions here: #7592 (comment).

Yes feeless_if is effective only if SkipCheckIfFeeless is used, usually wrapping the transaction payment extension.

So, iiuc, feeless_if won't have any effect without SkipCheckIfFeeless, but in this case, execution will still be free because of pays_fee: Pays::No, correct?

It would be free only if successful, people will have to pay for it, and they get refunded at the end of the transaction if is successful.

Next, if we add SkipCheckIfFeeless and pallet_skip_feeless_payment, and we change DispatchResultWithPostInfo to DispatchResult, then we no longer need the PostDispatchInfo { pays_fee: Pays::No, ... } code, right? (Probably because of prevent further transactions we want to keep it as it is here)

Yes, but it doesn't harm.

And lastly, when we make feeless_if + SkipCheckIfFeeless work with TransactionExtensions, how does it behave in the case of an extrinsic error? For example, if feeless_if passes and returns true, but fn apply_authorized_upgrade(..) fails on Self::can_set_code(..), will the user still be charged, or will it remain free?

if feeless_if passes, the user is never charged, (the transaction payment happens in the transaction extension in prepare phase, this payment will be skipped).
So if the transaction fails the changes in the call dispatch is reverted. So probably people will be able to spam a failing transaction for free.
Signer will not be charged after the failing of the transaction.

[bkontur]

@gui1117 Thank you :)

So if the transaction fails the changes in the call dispatch is reverted. So probably people will be able to spam a failing transaction for free.
Signer will not be charged after the failing of the transaction.

This is exactly what I was worried about :), but we probably just need to ensure that feeless_if is correct and covers all the necessary validations, right?

Also, another thing, here we are using/expecting an unsigned call: ValidateUnsigned::validate_unsigned(Call::apply_authorized_upgrade(..)). So, is this the spam protection mechanism that it doesn’t even add call to the transaction pool?