Why should transaction_version change with removals?

Question

transaction_version should increment if an extrinsic's parameters are modified. Same if an existing index changes for either an extrinsic or module.

That makes sense. If a transaction that used to be valid and has been modified such that it is now invalid, but could be valid.

It also does NOT need to change if we add NEW stuff.

I don't understand why transaction_version should change (as implied from the docs) if an extrinsic or module is removed.

Docs: https://paritytech.github.io/substrate/master/sp_version/struct.RuntimeVersion.html

This number must change when ...a dispatchable being removed, a module being removed...

Granted something can then construct a previously valid transaction, but will be rejected by the chain, but that doesn't appear to be a security risk.

Any additional details to help understand this requirement or is it old documentation from before #[pallet::call_index(n)]?

Answer 1

Any additional details to help understand this requirement or is it old documentation from before #[pallet::call_index(n)]?

Sort of yes. As long as all calls are using a fixed index, you remove one call and the index isn't reused, you don't need to bump the tx version. So, yeah you are right!

It isn't a security risk when the chain rejects the transaction. It is only a security risk if it may decodes to something different.

Answer 2

These are the best practices I think.

If you fix the index everywhere I think there is no need to update this version.

But why not just bump it for better safety? Sometimes you might forget to fix the index.