Add CLI Flag for chainID in txsim for improved transaction control

[staheri14]

Problem

txsim lacks a CLI flag for specifying the chain ID. Instead, it dynamically determines the chain ID by querying the target endpoint and assigns this ID to the generated transactions. This approach assumes that the transactions are intended for the same chain ID as the receiver's. However, if the endpoint changes its chain ID, submitting transactions may encounter issues, such as the master account having insufficient balance in the new chain or other failures due to a mismatch in chain IDs. This can create confusion for users trying to identify the root cause of the failure. Furthermore, there's a possibility that the transaction will succeed, but it might inadvertently be submitted to the wrong chain, diverging from the intended goal.

Solution

Providing user with a chain id flag to determine their intended chain.

[cmwaters]

This approach assumes that the transactions are intended for the same chain ID as the receiver's.

Can you give me an example where this is not the case

[staheri14]

This approach assumes that the transactions are intended for the same chain ID as the receiver's.

Can you give me an example where this is not the case

In a testing experiment, we encountered an issue where the endpoint was updated to a newer version of Mocha. This upgrade led to transaction failures because the account held funds on the old chain ID, but not on the newly upgraded one.

[cmwaters]

That makes sense, but in this scenario, if you had supplied a chain ID, the transaction would still fail because the node that you had submitted to belongs to the new chain.

I guess my point is that you should get the chainID from the node you're submitting transactions to because if it's not that chainID you will fail regardless. Perhaps the only reason for supplying the chainID is so that you can fail fast but you could perform some sanity checks on the endpoint before running the txsim

[staheri14]

That makes sense, but in this scenario, if you had supplied a chain ID, the transaction would still fail because the node that you had submitted to belongs to the new chain.

Right, however, if users could supply the chain ID and if a proper error message were shown for any mismatch between the endpoint and the intended chain ID, it would save a lot of debugging time in finding the root cause of failed transactions.

Perhaps the only reason for supplying the chainID is so that you can fail fast but you could perform some sanity checks on the endpoint before running the txsim

In my opinion, incorporating the chain ID in txsim and using it for the generated transactions would significantly enhance the user experience. Given that the chain ID is an integral part of a submitted transaction, it is more practical for users to specify it directly rather than having it inferred from the supplied endpoint. Additionally, if there's a mismatch between the chain ID and the endpoint, users could be notified to switch to an appropriate endpoint. This approach seems more user-friendly and efficient to me.

[cmwaters]

Actually most of the time the ChainID isn't known by the user. For example, if you're submitting a transaction on Keplr it derives the chain you are using based off the prefix in the account and works out the corresponding chainID you need to sign over. I was arguing that this made it simpler in terms of UX as it's one less variable the user has to find but that being said I don't find this decision too critical and am not opposed if we want to add the optional flag to the CLI.

[staheri14]

I was arguing that this made it simpler in terms of UX as it's one less variable the user has to find but that being said I don't find this decision too critical and am not opposed if we want to add the optional flag to the CLI.

I still support adding an optional flag for the chain ID. However, if there's insufficient interest in this feature, I will move forward with closing this issue.

[rootulp]

TBH I'm not strongly opinionated. I'm okay with the CLI flag or auto fetching it from the node. Will close for now b/c seems like we're not doing this soon.