CLI times out too quickly

[kevlubkcm]

Summary

A couple of times during cosmos mainnet launch, gaiacli would die with

Response:
ERROR: broadcast_tx_commit: Response error: RPC error -32603 - Internal error: Timed out waiting for tx to be included in a block

But the transaction was eventually successful. This seems very dangerous.
Not entirely sure what to do besides increase the timeout tho.
It isn't clear why a tx isn't being included.
Perhaps we can report at least if the tx is still sitting in peers' mempools?

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[joe-bowman]

@kevlubkcm you are able to append --async to any tx, which will return a tx hash, which you can subsequently run gaiacli query tx <hash> to check if it has been committed in a block.

Another option would be making this async the default behaviour - but then you'd have to change it everywhere to be consistent. So perhaps better messaging is the key.

[kevlubkcm]

I see. Thanks Yes, definitely should at least return a tx hash on sync time out so you can easily query later

…

On Thu, Mar 14, 2019, 4:49 AM Joe Bowman ***@***.***> wrote: @kevlubkcm <https://github.com/kevlubkcm> you are able to append --async to any tx, which will return a tx hash, which you can subsequently run gaiacli query tx <hash> to check if it has been committed in a block. Another option would be making this async the default behaviour - but then you'd have to change it everywhere to be consistent. So perhaps better messaging is the key. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3875 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Aiy5comyu-1tbbQ_-BVhEqlPMFg1OWzeks5vWg0MgaJpZM4byCkd> .

-- *ATTENTION:  This communication is not an investment recommendation or a solicitation to become a client of BKCM Funds, LLC or its parent company, BKCM LLC (collectively, “BKCM”). Unless indicated otherwise, the views or opinions set forth herein are the author's and may differ from those of BKCM or others in the firm. We do not represent that the information set forth in this communication is accurate or complete and we may not update this information. Past performance is not indicative of future returns. You should not use e-mail to request or authorize the investment in any security or instrument, or to effect any other transactions. We cannot guarantee that any such requests received via e-mail will be processed in a timely manner. This communication is intended solely for the addressee(s) and may contain confidential information. We do not waive confidentiality by mis-transmission. Contact me if you do not wish to receive these communications.** * *CONFIDENTIALITY NOTICE:  The information in this message, and any files transmitted with it, is confidential, may be legally privileged, and intended only for the use of the individuals(s) named above.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  Be aware that the use of any confidential or personal information may be restricted by state and federal privacy laws.  If you are not the intended recipient, do not further disseminate this message.  If this message was received in error, please notify the sender and delete it.*

[kevlubkcm]

maybe also add a query for txs in mempool? something like

gaiacli query mempool --tags signer:<address>

just to quickly get all pending txs?

[faboweb]

happens as well on REST inteface

[jackzampolin]

Agree on the mempool query as well.

[alexanderbez]

What do you see as the actionable items here @jackzampolin? Make async the default or increase the timeout? Or both?

[gamarin2]

I would increase the timeout

[jackzampolin]

I think making timeout configurable would be the best. Also increasing the default. I don't think we should make txs async by default.

[jackzampolin]

The mempool querying should be tracked by another issue.

[alexanderbez]

So I took a look through github.com/tendermint/tendermint/rpc/client and I don't see any direct way to set or modify the write timeout of a Client. Any light you can shed on this @ebuchman? If my suspicion is correct, then TM will need to be updated first (e.g. a SetWriteTimeout on the HTTPClient interface).

[jackzampolin]

Lets get this PR up

[ebuchman]

We might want to avoid using the broadcast_tx_commit all together here to avoid this.

[kevlubkcm]

What do you see as the actionable items here @jackzampolin? Make async the default or increase the timeout? Or both?

In addition to timeout increase, would be great if the command still returned a TxHash on failure so you can easily check later

[alexanderbez]

Correct me if I'm wrong, but what I believe @ebuchman is saying is that we remove the support for sync (BroadcastTxSync) tx broadcasting all together.

The more I think about this, the more this makes sense to me. Increasing the timeout will not really solve the problem as the mempool can fill dramatically and once complex fee markets start to spring up into existence, it can be a while before a tx is included into a block.

So I vouch that we remove the sync option OR at the very least, make async the default and clearly stipulate that sync can timeout where the tx will eventually be included.

What do you think?

[kevlubkcm]

that also makes sense to me

workflow looks more similar to say BTC/ETH (which i think would be familiar to most users) where you submit a tx and then wait to see it on a block explorer

[alexanderbez]

Precisely! A flow with which most users are already familiar with anyway.

[ebuchman]

it can be a while before a tx is included into a block.

Right.

In addition to timeout increase, would be great if the command still returned a TxHash on failure so you can easily check later

This would work too. We could just make the error message better and include the tx hash and instructions on what to do.

we remove the support for sync (BroadcastTxSync)

You mean BroadcastTxCommit ;). We want to use BroadcastTxSync instead.