Closed Kayanski closed 1 month ago
codecov[bot]
commented
1 month ago Attention: Patch coverage is 51.30435% with 56 lines in your changes missing coverage. Please review.
Project coverage is 54.9%. Comparing base (
59451dd) to head (2cd8a4e).
cloudflare-pages[bot]
commented
1 month ago 
Cloudflare Pages| Latest commit: |
2cd8a4e
|
| Status: | 🚫 Build failed. |
CyberHoward
commented
1 month ago Since we're working with the "interchain" I think get_chain is fine!
follow_packets -> await_packets?
follow_and check_packets -> await_packets_res?
follow_packets_from_txhash -> await_packets_for_tx?
Think it's nice to use await here as it indicates that the execution will wait for the packets to propagate (which isn't entirely clear for "follow").
Buckram123
commented
1 month ago This PR aims at making the cw-orch-interchain API AND docs better. The names of functions are still up for discussion, so here are the components that are used regularly :
* `get_chain(chain_id)` to get the chain (Mock, Daemon) associated with the chain id * This was renamed from `chain` to avoid conflicts with `Iterator::Chain` (that pops up inside rust-analyzer for some reason) * This could be renamed `environment`, as it's the method used inside contracts to get the execution environment
Have you considered just get? I guess we can have similar API to std::collections::HashMap since InterchainEnv is just collection of chains. Also regarding iterators, is it possible to imlpement Iterator of (ChainId, Chain) for InterchainEnv ?
* `follow_packets(tx_response)` that checks wether there are some packets inside a transaction result and follows the execution of all the packet sent during the transaction across remote chains. It also picks up other packets sent during the packet lifecycle (Receive, Ack, Timeout) and follows their execution. This returns when the packets have completed their cycle. (or it took too long and `cw-orch times-out)
I like follow_packets, could also be track_packets
* `follow_and check_packets(tx_response)`. This follows packets and **THEN** makes sure that: * There was no timeout * The resulting acknowledgments are successful. This last step is not possible for every packet type as there is no enforced standard for packet ack formats.
ensure_packets?
* `follow_packets_from_txhash(txhash: String)`. This queries the transaction response associated with the hash and then executes `follow_packets` on this transaction
follow_packets_txhash, track_packets_txhash
Kayanski
commented
1 month ago Have you considered just
get? I guess we can have similar API tostd::collections::HashMapsince InterchainEnv is just collection of chains. Also regarding iterators, is it possible to imlpement Iterator of(ChainId, Chain)forInterchainEnv?
The underlying objects are accessible on the env that we have, and devs can use it. I don't think it should be assumed that the underlying object is a HashMap though, because it doesn't have to be
Thanks for the other feedback
This PR aims at making the cw-orch-interchain API AND docs better. The names of functions are still up for discussion, so here are the components that are used regularly :
get_chain(chain_id)to get the chain (Mock, Daemon) associated with the chain idchainto avoid conflicts withIterator::Chain(that pops up inside rust-analyzer for some reason)environment, as it's the method used inside contracts to get the execution environmentfollow_packets(tx_response)that checks wether there are some packets inside a transaction result and follows the execution of all the packet sent during the transaction across remote chains. It also picks up other packets sent during the packet lifecycle (Receive, Ack, Timeout) and follows their execution. This returns when the packets have completed their cycle. (or it took too long and `cw-orch times-out)follow_and check_packets(tx_response). This follows packets and THEN makes sure that:follow_packets_from_txhash(txhash: String). This queries the transaction response associated with the hash and then executesfollow_packetson this transactionChecklist