Coder Social home page Coder Social logo

abstractsdk / cw-orchestrator Goto Github PK

View Code? Open in Web Editor NEW
69.0 6.0 15.0 6.79 MB

All-in-one Rust-based CosmWasm testing, scripting, and deployment tool.

Home Page: https://orchestrator.abstract.money

License: GNU General Public License v3.0

Shell 0.73% Rust 98.95% Just 0.07% Makefile 0.25%
blockchain deployment-automation rust scripting smart-contracts cosmwasm

cw-orchestrator's Introduction

cw-orchestrator

docs.rs Crates.io Codecov

A Rust tool for interacting with CosmWasm smart contracts. It provides a type-safe interface to CosmWasm contracts and allows you to easily interact with them. It does this by providing a set of macros that generate type-safe interfaces to your contracts. You can then combine your contract interfaces into a single object that can be shared with others to ease integration efforts and encourage collaboration.

The documentation here gives you a brief overview of the functionality that cw-orchestrator provides. We provide more documentation at orchestrator.abstract.money.

How it works

Interacting with a CosmWasm contract involves calling the contract's endpoints using the appropriate message for that endpoint (ExecuteMsg,InstantiateMsg, QueryMsg, MigrateMsg, etc.). cw-orchestrator generates typed interfaces for your contracts, allowing them to be type-checked at compile time. This generic interface then allows you to write environment-generic code, meaning that you can re-use the code that you write to deploy your application to cw-multi-test when deploying to test/mainnet.

Maintained Interfaces

We maintain a small set of interfaces ourselves that we use in our own projects. These interfaces are maintained by the Abstract team and are a good reference for how to use the library.

Codebase Latest Version
cw-plus GitHub tag (latest SemVer)
AbstractSDK Crates.io

Creating an Interface

In order to generate a typed interface to your contract you can pass the contract's message types into the cw_orch::interface macro.

The interface Macro

Provide your messages to a new struct that's named after your contract.

use cw_orch::interface;
use cw20_base::msg::{InstantiateMsg, ExecuteMsg, QueryMsg, MigrateMsg};

// Provide the messages in the order Init, Exec, Query, Migrate.
#[interface(InstantiateMsg, ExecuteMsg, QueryMsg, MigrateMsg)]
pub struct Cw20;

The macro will generate a new function that takes the contract name and the chain that you want to interact with. You can then use this interface to interact with the contract.

Usage

You can use this interface to deploy and interact with the contract:

use cw_orch::interface;
use cw_orch::prelude::*;
use cw20::{Cw20Coin, BalanceResponse};

// Implement the Uploadable trait so it can be uploaded to the mock. 
impl <Chain> Uploadable for Cw20<Chain> {
    fn wrapper() -> Box<dyn MockContract<Empty>> {
        Box::new(
            ContractWrapper::new_with_empty(
                cw20_base::contract::execute,
                cw20_base::contract::instantiate,
                cw20_base::contract::query,
            )
            .with_migrate(cw20_base::contract::migrate),
        )
    }
}


fn example_test() {
  let sender = Addr::unchecked("sender");
  // Create a new mock chain (backed by cw-multi-test)
  let chain = Mock::new(&sender);
  
  // Create a new Cw20 interface
  let cw20_base: Cw20<Mock> = Cw20::new("my_token", chain);
  
  // Upload the contract
  cw20_base.upload().unwrap();

  // Instantiate a CW20 token
  let cw20_init_msg = InstantiateMsg {
      decimals: 6,
      name: "Test Token".to_string(),
      initial_balances: vec![Cw20Coin {
          address: sender.to_string(),
          amount: 10u128.into(),
      }],
      marketing: None,
      mint: None,
      symbol: "TEST".to_string(),
  };
  cw20_base.instantiate(&cw20_init_msg, None, None).unwrap();

  // Query the balance
  let balance: BalanceResponse = cw20_base.query(&QueryMsg::Balance { address: sender.to_string() }).unwrap();

  assert_eq!(balance.balance.u128(), 10u128);
}

Features

cw-orchestrator provides two additional macros that can be used to improve the scripting experience.

ExecuteFns

The ExecuteFns macro can be added to the ExecuteMsg definition of your contract. It will generate a trait that allows you to call the variants of the message directly without the need to construct the struct yourself.

The ExecuteFns macro will only be applied on the Msg when compiled for non-wasm target.

use cw_orch::prelude::*;

#[cosmwasm_schema::cw_serde]
#[derive(cw_orch::ExecuteFns)]
pub enum ExecuteMsg {
    Freeze {},
    UpdateAdmins { admins: Vec<String> },
    /// the `payable` attribute can be used to add a `coins` argument to the generated function.
    #[cw_orch(payable)]
    Deposit {}
}

The generated functions can then be used for any interface that uses this ExecuteMsg.

// Define the interface, which is generic over the CosmWasm environment (Chain)
#[cw_orch::interface(Empty,ExecuteMsg,Empty,Empty)]
struct Cw1<Chain>;

impl<Chain> Cw1<Chain> {
    pub fn test_macro(&self) {
        // Enjoy the nice API! 
        self.freeze().unwrap();
        self.update_admins(vec!["new_admin".to_string()]).unwrap();
        self.deposit(&[Coin::new(13,"juno")]).unwrap();
    }
}

QueryFns

The QueryFns derive macro works in the same way as the ExecuteFns macro but it also uses the #[returns(QueryResponse)] attribute from cosmwasm-schema to generate the queries with the correct response types.

Nested types

For nested messages (execute and query), you just need to derive ExecuteFns or QueryFns on the underlying structures. In general, every structure that implements the Into trait for the contract message will make the function available on the contract. To make that clearer, her's an example:

use cw_orch::interface;
use cw_orch::prelude::*;

// An execute message that is generic.
#[cosmwasm_schema::cw_serde]
pub enum GenericExecuteMsg<T> {
    Generic(T),
}

// A type that will fill the generic.
#[cosmwasm_schema::cw_serde]
#[derive(cw_orch::ExecuteFns)]
pub enum Foo {
    Bar { a: String },
}


// Now we construct the concrete type with `Foo` in place of the generic.
type ExecuteMsg = GenericExecuteMsg<Foo>;
// And we implement the `From` trait (which auto-implements `Into`).
impl From<Foo> for ExecuteMsg {
    fn from(msg: Foo) -> Self {
        ExecuteMsg::Generic(msg)
    }
}

#[interface(Empty, ExecuteMsg, Empty, Empty)]
struct Example<Chain>;

impl<Chain: CwEnv> Example<Chain> {
    pub fn test_macro(&self) {
        // Function `bar` is available because `Foo` implements `Into<GenericExecuteMsg<Foo>>`
        self.bar("hello".to_string()).unwrap();
    }
}

WASM flagging

Cw-orch cannot be used inside smart contracts. In order to prevent you from having to add feature flags inside your smart-contract, the library excludes itself when building for the WASM target architecture. If you see errors during the build process like shown below, you will want to target-flag the related code:

error[E0432]: unresolved import `cw_orch::prelude`
 --> contracts/counter/src/interface.rs:4:26
  |
4 | use cw_orch::{interface, prelude::*};
  |                          ^^^^^^^ could not find `prelude` in `cw_orch`

error[E0432]: unresolved import `cw_orch::anyhow`
  --> contracts/counter/src/interface.rs:38:14
   |
38 | use cw_orch::anyhow::Result;
   |              ^^^^^^ could not find `anyhow` in `cw_orch`

error: cannot find macro `artifacts_dir_from_workspace` in this scope
  --> contracts/counter/src/interface.rs:19:9
   |
19 |         artifacts_dir_from_workspace!()
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0405]: cannot find trait `Uploadable` in this scope
  --> contracts/counter/src/interface.rs:16:13
   |
16 | impl<Chain> Uploadable for CounterContract<Chain> {
   |             ^^^^^^^^^^ not found in this scope

Just add the #[cfg(not(target_arch = "wasm32"))] to not include the code inside wasm builds:

#[cfg(not(target_arch = "wasm32"))]
mod interface;

Supported chains

Cw-orchestrator supports the following chains natively: ๐ŸŸฅ LocalNet, ๐ŸŸฆ Testnet, ๐ŸŸฉ Mainnet

  • Archway ๐ŸŸฆ๐ŸŸฉ
  • Injective ๐ŸŸฆ๐ŸŸฉ
  • Juno ๐ŸŸฅ๐ŸŸฆ๐ŸŸฉ
  • Kujira ๐ŸŸฆ
  • Migaloo ๐ŸŸฅ๐ŸŸฆ๐ŸŸฉ
  • Neutron ๐ŸŸฆ๐ŸŸฉ
  • Nibiru ๐ŸŸฆ
  • Osmosis ๐ŸŸฅ๐ŸŸฆ๐ŸŸฉ
  • Sei ๐ŸŸฅ๐ŸŸฆ๐ŸŸฉ
  • Terra ๐ŸŸฅ๐ŸŸฆ๐ŸŸฉ
  • Rollkit ๐ŸŸฅ๐ŸŸฆ
  • Xion ๐ŸŸฆ

Additional chains can easily be integrated by creating a new ChainInfo structure. This can be done in your script directly. If you have additional time, don't hesitate to open a PR on this repository.

Testing with OsmosisTestTube

OsmosisTestTube is available for testing in cw-orchestrator. In order to use it, you may need to install clang and go to compile the osmosis blockchain that serves as the backend for this env. This compilation is taken care of by cargo directly but if you don't have the right dependencies installed, weird errors may arise.

Installation

Cw-orch relies on external tools to work properly. Visit the INSTALL.md file for a list of dependencies and install commands that are needed for cw-orch to work properly on your machine.

Contributing

We'd really appreciate your help! Please read our contributing guidelines to get started.

Documentation

The documentation is generated using mdbook. Edit the files in the docs/src folder and run

just serve-docs

to view the changes.

Release Docs Dev Docs

Testing

To test the full application you can run the following command:

cargo test --jobs 1 --all-features

References

Enjoy scripting your smart contracts with ease? Build your contracts with ease by using Abstract.

Disclaimer

This software is provided as-is without any guarantees.

Credits

cw-orchestrator is inspired by terra-rust-api and uses cosmos-rust for protocol buffer gRPC communication.

cw-orchestrator's People

Contributors

adairrr avatar anistark avatar bhiiktor avatar buckram123 avatar cyberhoward avatar cyonis avatar dependabot[bot] avatar hoomp3 avatar jonhoo avatar kakucodes avatar kayanski avatar keyleu avatar mbbrainz avatar omahs avatar qrilka avatar wootteck avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

cw-orchestrator's Issues

Update syn to 2.0 + Better attributes management

Syn 2.0 provides better management for proc_macro parsing, and has a better way of managing attributes on them.
This would clarify the code as well as have it up to date with rust standards

Allow for default id in generated `new` function.

This code is currently generated for the contract macro.

        impl<Chain: ::boot_core::CwEnv> #name<Chain> {
            pub fn new(contract_id: &str, chain: Chain) -> Self {
                Self(
                    ::boot_core::Contract::new(contract_id, chain)
                )
            }
        }

We should have the ability to specify a default ID for the contract so we don't need to provide it on construction every time.

Doc-comments on nested fields not supported on `Fns` macros

#[cosmwasm_schema::cw_serde]
#[cfg_attr(feature = "boot", derive(boot_core::ExecuteFns))]
pub enum ExecuteMsg {
    UpdateMarketing {
        /// A URL pointing to the project behind this token.
        project: Option<String>,
        /// A longer description of the token and it's utility. Designed for tooltips or such
        description: Option<String>,
        /// The address (if any) who can update this data structure
        marketing: Option<String>,
    },
   ...
}

Allow for thread safe DaemonAsync out of the box

Today, DaemonAsync is thread safe but submitting transactions with a daemon between threads is not safe because of the account sequence not being updated accordingly when a transaction has been submitted in a block.

This represents the first step : #308

Solution

Wrap the account sequence in a mutex and update it to account for the account sequence change of possible transactions in the same block (is that even possible to have multiple txs in the same block ?)

Allow `mut` keyword in `boot_contract` prefixed endpoints

The change introduced by #77, doesn't allow endpoint to declare their variable using modifiers such as mut.
The following error appears :

error[E0561]: patterns aren't allowed in function pointer types

Origin

This issue comes from the macro saving the following function as a function pointer that doesn't allow such patterns.

Temporary fix

To fix this issue, simple replace

#[cfg_attr(not(feature = "library"), entry_point)]
#[cfg_attr(feature="boot", boot_contract)]
pub fn instantiate(
    mut deps: DepsMut,
    env: Env,
    info: MessageInfo,
    msg: InstantiateMsg,
) -> StdResult<Response> {
    ...

by

#[cfg_attr(not(feature = "library"), entry_point)]
#[cfg_attr(feature="boot", boot_contract)]
pub fn instantiate(
    deps: DepsMut,
    env: Env,
    info: MessageInfo,
    msg: InstantiateMsg,
) -> StdResult<Response> {
    let mut deps = deps;
    ...

Fix idea

We should remove the patterns on the arguments when saving the function pointer in a variable

Add support for test-tube as an execution environment.

The osmosis-test-tube is a FFI-based CosmWasm execution environment that can be used to test contracts that use app-chain specific logic without requiring a mock.

By adding support for this execution environment users get easy access to the Osmosis specific logic with possibly more chains supporting it in the future.

Feature: auto-request funds from testnet faucet if account is not found

It would be really nice to be able to request funds automatically from the faucet of the testnet if the account is not found:

Error: status: NotFound, message: "account terra1kg3c4twka4yq7we6jjgzcqvjn9xj95c2hw5fha not found", details: [], metadata: MetadataMap { headers: {"content-type": "application/grpc", "x-cosmos-block-height": "3769761"} }

Support gzipped contracts

Cosmos chains support the uploading of gzip'd wasm code (CosmWasm/wasmd#18), which helps get around the max gas allowed per block when uploading bigger smart contracts.

Currently, the WasmPath type returned by implementing the Uploadable trait requires that the file has an extension of .wasm.

There should be a way to support .wasm.gz extensions as well and/or compress the wasm with gzip before uploading it.

Add support for Terra

Terra has two different supported versions of CosmWasm which results in them having different gRPC URLs. To fix this we need to find a way to select which gRPC urls to use.

Feature-flag the Daemon

When using BOOT as a crate for integration testing it brings in a lot of unneeded imports which slows compilation.

By adding a feature flag to the Daemon-related functionality we can reduce compile times by a lot in testing environments.

Add IBC message reporting for daemons

By detecting IBC transactions and reporting on their status we should be able to remove the need for a developer to search for his TXs on block explorers.

The available cosmrs::proto::ibc::core::channel::v1 protobuf definitions allow for IBC channel queries to help facilitate this feature.

Gas price check

[2023-07-24T15:48:59Z DEBUG cw_orch::daemon::sender] tx broadcast response: TxResponse { height: 0, txhash: "4645A3D1313EE975373903AB2AAFADE9685391D41FF2B9D98CDEB9CEF35ECDD1", codespace: "sdk", code: 13, data: "", raw_log: "tx fee 1186807aarch is less than min fee: 5340366000000000000aarch: insufficient fee", logs: [], info: "", gas_wanted: 0, gas_used: 0, tx: None, timestamp: "", events: [] }

For networks like archway, when a transaction is submitted without enough gas, it doesn't fail the transaction, but rather gives a raw_log with the failure. We should be able to detect this and notify the deploying user.

2023-07-24T15:54:22Z DEBUG cw_orch::daemon::tx_builder] Simulated gas needed 139752
[2023-07-24T15:54:22Z DEBUG cw_orch::daemon::tx_builder] Calculated fee needed: 1.677024e17
[2023-07-24T15:54:22Z DEBUG cw_orch::daemon::tx_builder] submitting tx:
     fee: Fee { amount: [Coin { denom: Denom("aarch"), amount: 167702400000000000 }], gas_limit: 167702, payer: None, granter: None }
    account_nr: 207303
    sequence: 11
[2023-07-24T15:54:22Z DEBUG cw_orch::daemon::sender] tx broadcast response: TxResponse { height: 0, txhash: "115E535194D871641D71617EB96C9C4AFDC9D6E8C64E4843BCCEED7B21002040", codespace: "", code: 0, data: "", raw_log: "[]", logs: [], info: "", gas_wanted: 0, gas_used: 0, tx: None, timestamp: "", events: [] }


[2023-07-24T15:54:29Z DEBUG cw_orch::contract] execute response: Err(TxFailed { code: 11, reason: "out of gas in location: WriteFlat; gasWanted: 167702, gasUsed: 168419: out of gas" })

Add support for `cosmwasm_std::Response<T>` with non-empty response trait

Default type used for Response is cosmwasm_std::Response<cosmwasm_std::Empty> which is fine in most situations.

However, attempt to use custom trait type with cw_orch::interface_entry_point results in compilation error:

error[E0308]: mismatched types
  --> src/contract.rs:16:1
   |
16 | #[cfg_attr(feature = "interface", cw_orch::interface_entry_point)]
   | ^
   | |
   | expected struct `Empty`, found enum `NeutronMsg`
   | expected `Result<cosmwasm_std::Response, cw_orch::anyhow::Error>` because of return type
   |
   = note: expected enum `Result<cosmwasm_std::Response<cosmwasm_std::Empty>, _>`
              found enum `Result<cosmwasm_std::Response<NeutronMsg>, _>`
   = note: this error originates in the attribute macro `cw_orch::interface_entry_point` (in Nightly builds, run with -Z macro-backtrace for more info)

Example to reproduce

#[cfg_attr(not(feature = "library"), cosmwasm_std::entry_point)]
#[cfg_attr(feature = "interface", cw_orch::interface_entry_point)]
pub fn instantiate(
    _deps: DepsMut,
    _env: Env,
    _info: MessageInfo,
    _msg: InstantiateMsg,
) -> ContractResult<Response<neutron_sdk::bindings::msg::NeutronMsg>> { Ok(Response::new()) }

Note: this example depends on https://crates.io/crates/neutron-sdk

Add warning when logger is not configured

When running cw-orchestrator with no logs, nothing happens until the script stops.
Because cw-orchestrator is way better with at least the info logs, we have to at least warn the user that logs are available if not force at least an info log level.

Proposal

If the RUST_LOG level is not set, make the daemon environment set it to info, so that for un-experienced users, the execution info is visible by default.

Auto generate contract endpoint functions

The requirement to implement the contract's endpoint calls manually is not a good developer experience.

It should be possible to create a macro that generates the scripting functions for the contract.

Remove verbose logging of GRPC connections

When executing against a daemon, cw-orch produces too much logs that indicate the application is connecting to a grpc. Especially in the context of clone-testing , this grpc connection is done repeatedly and pollutes the log produced.

We should change the log level from info to debug for thos logs.

This is the result today :


[2023-11-16T09:44:49Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:49Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:49Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:49Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:49Z INFO  cavern] A currency balance before deposit : BalanceResponse { balance: Uint128(9971409) }
[2023-11-16T09:44:49Z INFO  Contract] Executing DepositStable on cavern:money-market
[2023-11-16T09:44:49Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:49Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:49Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:49Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:50Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:50Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:50Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:50Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:50Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:50Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:50Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:50Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:50Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:50Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:51Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:51Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:51Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:51Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:51Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:51Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:51Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:51Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:51Z INFO  Contract] Executed cavern:money-market with address terra1zqlcp3aty4p4rjv96h6qdascdn953v6crhwedu5vddxjnp349upscluex6
[2023-11-16T09:44:51Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:51Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790
[2023-11-16T09:44:52Z INFO  cavern] A currency balance after deposit : BalanceResponse { balance: Uint128(9980466) }
[2023-11-16T09:44:52Z INFO  cw_orch_daemon::channel] Trying to connect to endpoint: http://terra-grpc.polkachu.com:11790

Retry on transaction errors

Description

When submitting a transaction with cw-orch, you might get some errors that are common when using blockchain nodes.
Those errors stop the execution and it is difficult to restart the execution from where it stopped.
Those errors include :

  1. Account sequence errors (due to nodes being not perfectly in sync)
  2. Out of gas errors (due to wrong gas computation, usually due to a wrong gas_adjustment parameter)

Solution

Those errors could be caught directly in the commit_tx function and retried as long as the error is one of the listed errors above.
This should not be done without a direct consent from the user (and with a refresh rate not too high), because submitting a failed transaction costs funds.

Specifics

  1. In order to solve the account sequence error, one only needs to wait a few seconds for all the nodes to be updated with the most recent block. This error is located when submitting the tx (or simulating, not sure) and doesn't cost gas to the user
    --> This could be solved by matching incorrect account sequence in the transaction error response.

  2. In order to solve the out of gas errors, the gas adjustment parameter needs to be uped each time this is encountered. The gas needed return value from the node SOULD NOT be used as this is not accurate at all. This error should only be retried upon with a user prompt. This would securise the mechanism. An env variable could allow for non-interacting retries as well.

Allow for storing multiple deployment states

By adding an optional deployment identifier to the Daemon it should be possible to store deployment state under a custom identifier. Allowing for multiple deployments on the same daemon (chain).

Add Query/Execution traits for execution environments

Create a common interface for Queries/Execution on different execution environments. The idea is to be able to call on any CwEnv environment :

let chain: CwEnv = ...
chain.send_funds(coin(34, "ujuno"))?;

let balance = chain.balance("<my-address>")?;

Unable to cargo build or compile to wasm if the #[payable] attribute is present on an execute function.

My contract setup looks very similar to the counter example here: https://github.com/AbstractSDK/cw-orchestrator/tree/main/contracts/counter

When I try to build or compile to wasm I get the same error:

error: cannot find attribute `payable` in this scope
  --> src\msg.rs:39:7
   |
39 |     #[payable]
   |       ^^^^^^^

error: could not compile `ymos-swap-router` (lib) due to previous error

Here is my cargo.toml:

exclude = [
  # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication.
  "contract.wasm",
  "hash.txt",
]

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[profile.release]
opt-level = 3
debug = false
rpath = false
lto = true
debug-assertions = false
codegen-units = 1
panic = 'abort'
incremental = false
overflow-checks = true

[lib]
crate-type = ["cdylib", "rlib"]

[features]
default = ["export"]
export = []
interface = ["dep:cw-orch"]
# for more explicit tests, cargo test --features=backtraces
backtraces = ["cosmwasm-std/backtraces"]
# use library feature to disable all instantiate/execute/query exports
# library = []

[package.metadata.scripts]
optimize = """docker run --rm -v "$(pwd)":/code \
  --mount type=volume,source="$(basename "$(pwd)")_cache",target=/code/target \
  --mount type=volume,source=registry_cache,target=/usr/local/cargo/registry \
  cosmwasm/rust-optimizer:0.12.10
"""

[dependencies]
cosmwasm-schema = "1.1.3"
cosmwasm-std = "1.1.3"
cosmwasm-storage = "1.1.3"
cw-storage-plus = "1.0.1"
cw2 = "1.0.1"
schemars = "0.8.10"
serde = { version = "1.0.145", default-features = false, features = ["derive"] }
thiserror = { version = "1.0.31" }
wyndex-multi-hop = { git = "https://github.com/wynddao/wynddex.git", tag = "v2.0.3", features = ["library"] }
white-whale = { git = "https://github.com/White-Whale-Defi-Platform/white-whale-core.git", tag = "v1.4.0-juno-1-token_factory-hotfix" }
cw20 = "1.1.0"
tokio = "1.32.0"
env_logger = "0.10.0"
anyhow = "1.0.75"
dotenv = "0.15.0"
log = "0.4.20"
cw-orch = { version = "0.16.4", optional = true }

[dev-dependencies]
cw-orch = {  version = "0.16.4", features = ["daemon"] }
ymos-swap-router = { path = ".", features = ["interface"] }
dotenv = "0.15.0"

And here is the Execute enum:

#[cw_serde]
#[cfg_attr(feature = "interface", derive(cw_orch::ExecuteFns))]
pub enum ExecuteMsg {
    SetRoutes {
        routes: Vec<((String, String), Vec<SwapRoute>)>,
    },

    #[payable]
    Swap {
        token_in: Coin,
        token_out: String,
    },
}

Store version in daemon_state

It would be a better experience for developers if the version of the deployment was stored along the contract name.

Right now, new versions of modules overwrite the existing entry for code_ids.

For example:

{
  "juno": {
    "uni-6": {
      "code_ids": {
        "abstract:version-control:0.14.0": 1581
      },
      "default": {
        "abstract:version-control:0.14.0": "juno1hl4h9qf6g4ysh4e7fkx8lcvsymtfc8ntxwhuvnxja7ugz357sukq74pdmn"
      }
    }
  },

Add migration helpers

When migrating an app structure, you want helpers to help you migrate every contract.
You want to deploy your old structure, migrate to your new one and test that everything is working properly. We need helpers on the Deploy trait or around that facilitate this work

Enable gas profiling

Add a gas profiler to easily collect gas-usage data over different deployments.

Move environments to their own crate

Because of the continual development of BOOT, new version are often released. Because trait implementations between versions are not considered compatible any bump to the boot-core crate causes issues for compatibility between users.

To solve this we can move the BOOT environments to a separate crate which allows us to develop and add new environments without requiring new boot-core releases. This should help us keep API stability for the key BOOT features without strangling our ability to add/update the environments.

Archway constantine-3 rpc url is not valid anymore

packages/cw-orch-networks/src/networks/archway.rs

[2024-06-14T11:08:50Z WARN  cw_orch_daemon::channel] Cannot connect to gRPC endpoint: https://grpc.constantine.archway.tech:443, tonic::transport::Error(Transport, hyper::Error(Connect, ConnectError("dns error", Custom { kind: Uncategorized, error: "failed to lookup address information: Name or service not known" })))
[2024-06-14T11:08:50Z WARN  cw_orch_daemon::channel] Cannot connect to gRPC endpoint: https://grpc.constantine.archway.tech:443, tonic::transport::Error(Transport, hyper::Error(Connect, ConnectError("dns error", Custom { kind: Uncategorized, error: "failed to lookup address information: Name or service not known" })))

Resumable Deployment Observer

It would be beneficial to the developer experience if in-progress deployments were kept track of, and were able to be resumed at a given point if a step fails.

Right now, if you have a script that deploys many interlinked contracts and one of the deployments / actions fails, the script fails entirely with dangling contracts in an unknown state. With the deployment observer, the latest step and state would be known and could be resumed before the failure.

This would likely use the observer pattern where each step executing an action using the Boot ContractInstance would increment the step counter and save the state at that step. If a deployment "resumes" (via flag or otherwise) it would see that the step counter is > 0 and resume after the latest successful step.

Broken 0.16.4 release

I noticed failing CI on the abstract nightly build for cw-orch version 0.16.4.

cw-orch depends on osmosis-test-tube v19.0.0 which was recently bumped to v19.2.0 (which should be version compatible).

However a major bump in osmosis-std (v0.19 -> v0.20) was included in the update, causing type version mis-matches as shown below:

error: could not compile `cw-orch` (lib) due to 4 previous errors
error[E0308]: mismatched types
   --> cw-orch/src/osmosis_test_tube/core.rs:159:33
    |
159 |               .query_all_balances(&QueryAllBalancesRequest {
    |  ______________------------------_^
    | |              |
    | |              arguments to this method are incorrect
160 | |                 address: address.to_owned(),
161 | |                 pagination: None,
162 | |             })
    | |_____________^ expected `QueryAllBalancesRequest`, found a different `QueryAllBalancesRequest`
    |
    = note: `QueryAllBalancesRequest` and `QueryAllBalancesRequest` have similar names, but are actually distinct types
note: `QueryAllBalancesRequest` is defined in crate `osmosis_std`
   --> /Users/robin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/osmosis-std-0.19.1/src/types/cosmos/bank/v1beta1.rs:326:1
    |
326 | pub struct QueryAllBalancesRequest {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: `QueryAllBalancesRequest` is defined in crate `osmosis_std`
   --> /Users/robin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/osmosis-std-0.20.1/src/types/cosmos/bank/v1beta1.rs:326:1
    |
326 | pub struct QueryAllBalancesRequest {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = note: perhaps two different versions of crate `osmosis_std` are being used?
note: method defined here
   --> /Users/robin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/test-tube-0.1.9/src/module/bank.rs:35:13
    |
35  |         pub query_all_balances ["/cosmos.bank.v1beta1.Query/AllBalances"]: QueryAllBalancesRequest => QueryAllBalancesResponse
    |             ^^^^^^^^^^^^^^^^^^

Running cargo tree -i for both versions reveals:

$ cargo tree -i [email protected]
osmosis-std v0.20.1
โ””โ”€โ”€ test-tube v0.1.9
    โ””โ”€โ”€ osmosis-test-tube v19.2.0
    
$ cargo tree -i [email protected]
osmosis-std v0.19.2
โ””โ”€โ”€ osmosis-test-tube v19.2.0

Steps to reproduce:

git checkout v0.16.4
cargo build --all-features

Allow using Generics in `contract` macro

It should be possible to create a contract interface using Generics such as

#[contract(InstantiateMsg<A>, ExecuteMsg<B, C>,QueryMsg<D>, MigrateMsg<E>)]
pub struct Contract;

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.