bug: Running `prove_block` in an async context fails

[akhercha]

SNOS version: rev 7cde766

Current behavior:

We're trying to execute the prove_block function in an async context, but it fails with the error:

Rc<blockifier::execution::contract_class::ContractClassV1>` cannot be sent between threads safely... # see below for more

Expected behavior:

The function should be callable without any compile time error.

Steps to reproduce:

Locally

1. Clone the madara-orchestrator repo & go into the branch:

git clone git@github.com:astraly-labs/madara-orchestrator.git
cd madara-orchestrator
git checkout feat/snos_job

You will need to go directly into the ~/.cargo/git/ snos dependency folder to build the OS files manually, using ./scripts/setup-tests.sh.

2. Find the buggy code

Current code is located in crates/orchestrator/src/jobs/snos_job/mod.rs:

async fn process_job(&self, config: &Config, job: &mut JobItem) -> Result<String, JobError> {
    let block_number = self.get_block_number_from_metadata(job)?;
    let rpc_url = get_env_var_or_panic("MADARA_RPC_URL"); // should never panic at this point

    let (cairo_pie, snos_output) =
        prove_block(block_number, &rpc_url, LayoutName::all_cairo).await.map_err(SnosError::from)?;

    self.store(config.storage(), job.internal_id, block_number, cairo_pie, snos_output).await?;

    Ok(String::from("TODO: ID"))
}

This code will never compiles because of this error:

`Rc<blockifier::execution::contract_class::ContractClassV1>` cannot be sent between threads safely
within `(Felt252, starknet_os_types::casm_contract_class::GenericCasmContractClass)`, the trait `std::marker::Send` is not implemented for `Rc<blockifier::execution::contract_class::ContractClassV1>`, which is required by `{async block@crates/orchestrator/src/jobs/snos_job/mod.rs:77:97: 87:6}: std::marker::Send`
required because it appears within the type `(Felt252, starknet_os_types::casm_contract_class::GenericCasmContractClass)`
required for `hashbrown::raw::RawTable<(Felt252, starknet_os_types::casm_contract_class::GenericCasmContractClass)>` to implement `std::marker::Send`
required for the cast from `Pin<Box<{async block@crates/orchestrator/src/jobs/snos_job/mod.rs:77:97: 87:6}>>` to `Pin<Box<dyn futures::Future<Output = std::result::Result<std::string::String, jobs::JobError>> + std::marker::Send>>`

Replacing the code by:

async fn process_job(&self, config: &Config, job: &mut JobItem) -> Result<String, JobError> {
    let block_number = self.get_block_number_from_metadata(job)?;
    let rpc_url = get_env_var_or_panic("MADARA_RPC_URL"); // should never panic at this point

    // let (cairo_pie, snos_output) =
    //     prove_block(block_number, &rpc_url, LayoutName::all_cairo).await.map_err(SnosError::from)?;

    let cairo_pie = todo!();
    let snos_output = todo!();

    self.store(config.storage(), job.internal_id, block_number, cairo_pie, snos_output).await?;

    Ok(String::from("TODO: ID"))
}

will make it compile.

Through docker

FROM rust:1.81.0-bullseye

WORKDIR /usr/src/madara-orchestrator

RUN apt-get update && apt-get install -y git

RUN git clone https://github.com/astraly-labs/madara-orchestrator.git . && \
    git checkout feat/snos_job

CMD cargo build

Build it & try to run it:

docker build . -t madara-o-bug
docker run madara-o-bug

Currently it will fail earlier with:

error: couldn't read `/usr/local/cargo/git/checkouts/snos-59fe8329bb16fe65/0bc8055/crates/starknet-os/src/../../../build/os_latest.json`: No such file or directory (os error 2)
  --> /usr/local/cargo/git/checkouts/snos-59fe8329bb16fe65/0bc8055/crates/starknet-os/src/config.rs:26:40
   |
26 | pub const DEFAULT_COMPILED_OS: &[u8] = include_bytes!("../../../build/os_latest.json");
   |                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in the macro `include_bytes` (in Nightly builds, run with -Z macro-backtrace for more info)

Until this is fixed.

[notlesh]

I implemented two easy fixes for this in #368. We may try to find a better solution, but in the meantime you can use this as a workaround.

[akhercha]

Just used your branch and it fixed the issues - thanks!