Misleading usability with `create_partial_offline` and mortal txs

[iulianbarbu]

I am a subxt newbie, and to some extent, a polkadot newbie, and I would assume lots of developers can be in the situation where the API and the docs are still confusing (although to the majority of cases it is very well written and precise), so that when they configure some tx params with mortality, used to create an offline transaction, they notice in the end it is submitted as immortal.

Using create_partial_offline shouldn't allow passing over params that have configured mortality. Should allow only certain params that are compatible with the offline transaction creation. Not sure how feasable it is, but the whole point of the issue here is to question whether it is possible for create_partial_offline to accept a certain OfflineTxParams type/trait (corresponding to txs that are created offline), where we can suggest better through the API what's possible (e.g. mortal setter will not exist for such a transaction). At the same time, if the mortality will be the only thing different between OfflineTxParams and OnlineTxParams, I can understand why this suggestion wouldn't be very valuable. I would go for it nonetheless, curious about opinions.

[jsdw]

Hello!

Sorry; I don't 100% understand what you're trying to suggest offhand?

Using create_partial_offline shouldn't allow passing over params that have configured mortality

There's nothing wrong with creating a mortal transaction offline :)

One thing to be aware of is that if for online transactions (ie api.tx().create_partial(..) rather than api.tx().create_partial_offline(..)), if you explicitly set the transaction to be immortal than it will be, but if you don't explicitly set the mortality at all then subxt will set it to be mortal by default.

Perhaps I'm missing your point though?

[iulianbarbu]

There's nothing wrong with creating a mortal transaction offline :)

How to do it? My approach was to use create_partial_offline and pass to it a DefaultExtrinsicParams where I set the mortality through the mortal setter. However, after signing the tx and submitting, the tx appears as immortal on chain.

One thing to be aware of is that if for online transactions (ie api.tx().create_partial(..) rather than api.tx().create_partial_offline(..)), if you explicitly set the transaction to be immortal than it will be, but if you don't explicitly set the mortality at all then subxt will set it to be mortal by default.

I am not concerned with this case. I am using the online client though whenever I need to create a mortal tx, and I set the mortality to a certain value.

Perhaps I'm missing your point though?

Not sure, my point is that I can't seem to be able to create a mortal transaction with the offline client given the API (e.g. create_partial_offline + DefaultExtrinsicParams with mortality set still submits immortal txs), but after reading closer the docs and the code things were clarified. My understanding is that only by using an online client I'd be able to create an actual mortal tx.

[jsdw]

Edit: I see you posted just before I clicked send on this one, but hopefully this comment addresses things!

Ah, no, there is a bit more which I can see is confusing!

If you configure extrinsic params like DefaultExtrinsicParamsBuilder::new().mortal(32) to be mortal for 32 blocks, then an online transaciton will honour this, and an offline transaction will discard this. This is because the offline transaction doesn't have enough information to work with and so is unabgle to honour it.

Instead, you have to use an APi which is slightly more obscured but essentially do this to actually set mortality offline:

let params = DefaultExtrinsicParamsBuilder::new();

params.5 = CheckMortalityParams::mortal_from_unchecked(for_n_blocks, from_block_n, from_block_hash);

// now if you pass therse params to an offline tx it will still be mortal.

I think it may be too difficult/weird to have separate traits or something to handle offline vs online here, but we should definitely improve the documentation and expose the mortal_from_unchecked type function from the DefaultExtrinsicParamsBuilder!

Let me look at the APIs here and see what I can do!

[iulianbarbu]

I think it may be too difficult/weird to have separate traits or something to handle offline vs online here, but we should definitely improve the documentation and expose the mortal_from_unchecked type function from the DefaultExtrinsicParamsBuilder!

Probably it is not straight forward yeah. Maybe besides docs and exposing mortal_from_unchecked we can also validate the params and error in case they aren't set as expected (e.g. for create_partial_offline expect mortal_from_unchecked - I expect to be doable since I saw that in create_partial we inject the block and account nonce - so down the line even if things are abstracted away at the higher levels, we're still making sure the mortality is rightly configured for online client).

[jsdw]

Maybe besides docs and exposing mortal_from_unchecked we can also validate the params and error in case they aren't set as expected (e.g. for create_partial_offline expect mortal_from_unchecked - I expect to be doable since I saw that in create_partial

Yeah that's true; we may be able to make it such that you get an error back if you set a mortality which can't ultimately be honoured! It would be better than just changing it to immortal and submitting! Let me look at the code and see what makes more sense here in the end!

[jsdw]

This was addressed in #2025 along with some other things that cropped up in the area :)