Closed Kayanski closed 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
).
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").
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
Have you considered just
get
? I guess we can have similar API tostd::collections::HashMap
since 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 idchain
to 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_packets
on this transactionChecklist