Cosmos: Handle (sign and) broadcast errors

[gomesalexandre]

Overview

Currently, we have no way to handle failed to broadcast errors and don't notify users about it, it just silently fails (with some unchained errors logged in console). As a user, I would like to know why my Tx failed.

References and additional details

Currently known errors:

• MaxEntries reached, see https://blog.cosmos.network/re-delegations-in-the-cosmos-hub-7d2f5ea59f56 - this error happens when the maximum amount of undelegations has been reached. It is defined in cosmos-sdk as ErrMaxUnbondingDelegationEntries. Note: It is not currently handled by unchained and the Tx will be broadcasted, but fail. From the client perspective though it will just be like any broadcasted Tx.
• Mempool is full. Technically not a Cosmos error, but rather an error from the node provider
• incorrect account sequence. This ones can potentially happen when staking/unstaking twice in a row

Acceptance Criteria

• All errors that we are aware of of are shown with a toast at broadcast level, similarly to the send flow
• Other errors are displayed with a generic toast message
• The implementation can handle both unchained broadcast errors (the only ones that should happen currently), as well as be able to easily iterate and add signing errors (e.g user rejected the transaction) when Keplr will be ready

Need By Date

No response

Screenshots/Mockups

No response

Estimated effort

No response

[0xean]

Low priority and blocked by fixes in unchained to surface these errors to web

[0xdef1cafe]

@gomesalexandre is this tackled with defi changes?

[0xdef1cafe]

has to be tackled in unchained

[0xdef1cafe]

closing as stale