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

Use send_tx directly in ChainDriver for integration test #2205

Merged
merged 11 commits into from
May 11, 2022

Conversation

soareschen
Copy link
Contributor

Closes: #2012
Prerequisite for: #1981

Description

This is a follow up on #2044 to use send_tx directly in ChainDriver for integration test. This allows us to write tests that send arbitrary transactions with any wallet inside the integration test.

Prior to this, we have the limitation that transactions have to be submitted via the gaiad command, with quirks like #2012. Otherwise the ChainHandle design has the limitation of having a global wallet that is tied to the relayer, which makes it very tricky to submit transactions using multiple non-relayer wallets.

This is required for #1981 so that we can send atomic transaction that include MsgPayPacketFee, as well as submitting MsgPayPacketFeeAsync using the user wallet. Without this, it will be problematic to do this via gaiad, and it is unclear whether the gaiad CLI currently supports IBC transfer with packet fee. This PR makes it straightforward for us to submit such transactions directly, as long as there is a protobuf definition that can convert the domain type into prost::Any.


PR author checklist:

  • Added changelog entry, using unclog.
  • Added tests: integration (for Hermes) or unit/mock tests (for modules).
  • Linked to GitHub issue.
  • Updated code comments and documentation (e.g., docs/).

Reviewer checklist:

  • Reviewed Files changed in the GitHub PR explorer.
  • Manually tested (in case integration/unit/mock tests are absent).

Introduce TxConfig

Add test constructor for TxConfig

Add send_tx method on ChainDriver

Accept Wallet instead of WalletAddress for transferring tokens

Implement ibc_token_transfer

Simplify ibc_token_transfer

Token transfer using ibc_token_transfer is now working
@soareschen soareschen marked this pull request as ready for review May 11, 2022 09:20
@soareschen soareschen requested review from mzabaluev and removed request for seanchen1991 May 11, 2022 09:21
{
info!("sending first IBC transfer after client is expired. this should cause packet worker to fail");

chains.node_a.chain_driver().transfer_token(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests here has to be removed, because since Gaia v7 the transaction will fail. Apparently we didn't catch this error previously, because submitting the transaction via the gaiad command do not result in error.

@soareschen soareschen merged commit bbd5ed8 into master May 11, 2022
@soareschen soareschen deleted the soares/direct-send-tx branch May 11, 2022 17:51
hu55a1n1 pushed a commit to hu55a1n1/hermes that referenced this pull request Sep 13, 2022
…lsystems#2205)

* Add simple_send_tx

Introduce TxConfig

Add test constructor for TxConfig

Add send_tx method on ChainDriver

Accept Wallet instead of WalletAddress for transferring tokens

Implement ibc_token_transfer

Simplify ibc_token_transfer

Token transfer using ibc_token_transfer is now working

* Move AddressType into TxConfig, as it is configured per chain

* Disable GRPC Web and not rely on chain version

* Clean up ibc_transfer_token interface on ChainDriver

* Use longer IBC transfer timeout

* Further increase IBC transfer timeout

* Fix client expiration test in gaia7

* Move tx_raw_ft_transfer to simulation test

* Modularize ibc_token_transfer
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ChainDriver::transfer_token() does not perform subsequent IBC transfer when called multiple times
2 participants