Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intercept and Format Tendermint Broadcast Errors #4972

Closed
1 of 4 tasks
alexanderbez opened this issue Aug 29, 2019 · 0 comments · Fixed by #4996
Closed
1 of 4 tasks

Intercept and Format Tendermint Broadcast Errors #4972

alexanderbez opened this issue Aug 29, 2019 · 0 comments · Fixed by #4996
Assignees
Labels
good first issue T: Dev UX UX for SDK developers (i.e. how to call our code)

Comments

@alexanderbez
Copy link
Contributor

alexanderbez commented Aug 29, 2019

Summary

Through the CLIContext, we can broadcast signed txs in one of three ways: async, sync, and block via node.BroadcastTx*. Regardless of the mode, all the modes return a (Result*, error).

Problem Definition

When calling node.BroadcastTx* we get no error and a valid Result* if the tx successfully executed (depending on the mode). This means the client will get a TxResponse returned back.

However, there are a few cases where an error can be returned from Tendermint because the tx wasn't even executed at all. Namely, ErrTxTooLarge, ErrPreCheck, and ErrTxInCache. When these errors are returned, it would be nice for clients to still get back a TxResponse with an appropriate code.

Proposal

During node.BroadcastTx*, intercept the error and check if it's any of the above mentioned. If so, map that to an SDK error code and return a TxResponse.

e.g.

	if err != nil {
		switch err {
		case mempool.ErrTxInCache:
			return sdk.TxResponse{Code: ...}, nil
		}
	}

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@alexanderbez alexanderbez added good first issue T: Dev UX UX for SDK developers (i.e. how to call our code) labels Aug 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue T: Dev UX UX for SDK developers (i.e. how to call our code)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants