Sandbox Runtime

[ChaoticTempest]

Rough implementation of SandboxRuntime: not everything is in place, but works for the most part in testing things locally. Also, to make it more idiomatic to rust's runtime libraries, there's no concept of Runner implemented, since Runtime is basically the runner.

• After this PR, will rename the repo to runner-rs.
• All the helper functions got moved to runner/rpc/api.rs, but will likely be changed over to use NAR after this PR gets merged.
• SandboxRuntime has been added, but mainnet and testnet runtimes are not implemented yet (should be easy in a future ticket to implement and hopefully not "famous last words").

Sample usage:

use runner::*;

#[runner::test(sandbox)]
async fn test_deploy() {
    let (contract_id, signer) = dev_deploy(Path::new("path/to/file.wasm"))
        .await
        .expect("could not dev-deploy contract");

    let result = view(
        contract_id,
        "function_name".to_string(),
        r#""some_arg": "some_value""#.into(),
    ).await.expect("could not call into view function");

    assert_eq!(result, OUR_EXPECTED_RESULT);
}

or using it within a binary directly like so:

use runner::*;

#[runner::main(sandbox)]
async fn main() {
}

The hope is we can have #[runner::test(testnet)] and #[runner::test(mainnet)] options too, which do work, but just the runtime hasn't been implemented for those.

Let me know if there's anything anybody doesn't understand. The design for the runtime was mainly taken from tokio itself.

[austinabell]

tests don't work locally because we have diff sandbox binary locations. I'll dig more into the internals when I can test things by running

[austinabell]

I'm a little confused by this, because if used asynchronously wouldn't this cause race conditions where another thread/task would access the modified environment rather than the intended one?

[ChaoticTempest]

This was also another thing I took from tokio. This is behind a thread_local so using it asynchronously shouldn't be an issue. You can also take a look at how tokio uses it context::enter

There is another case where the runtime is multi-threaded, but the runtime will do the thread spawning directly instead of the developer. During thread spawning we also call enter for that specific thread to have this runtime context as well. But the current rt implementation is only single threaded.

[ChaoticTempest]

tests don't work locally because we have diff sandbox binary locations. I'll dig more into the internals when I can test things by running

@austinabell Ahh, yea sorry about that. Just hardcoded it for now (base on my binary location) so there's proper cleanup after the test finishes. We just need to have a cargo crate of the sandbox binary or a utility that can easily fetch the sandbox location if we install it thru npm.

[austinabell]

Seems like a decent starting point, as long as the install and binary usage is updated, sleeps are updated to not be so rigid, and certain interfaces are cleaned up in another PR.

Definitely want to make this accessible for anyone to use without assuming a specific binary location of something installed externally to test this

[austinabell]

Can we swap this to be generic on serde deserialize to not have to go through serde_json::Value if a caller doesn't want? (prob in another PR)

[ChaoticTempest]

yea definitely. A lot of the RPC calls need to be re-evaluated too. I'll make a ticket for another PR later once this merges

[willemneal]

Approved, just have one comment about the type name flavor over network or even endpoint.