Pocket-ic wasm size limit other than IC?

Developers
1

Hi, does Pocket-ic have other restrictions on wasm size than IC in general. I have no problems running my canister locally or deploying to mainnet. But, when using pocket-ic:

Failed to submit ingress message: Request 0x73f6562d82a01782d062f91443751263bd72382d3fd4fa925bc4dadfebb6eeef is too large. Message byte size 2546230 is larger than the max allowed 2097152.

WASM ia gzipped already.

@michael-weigelt

1 Like
2

On an application subnet, the limit is at 2M just like in PocketIC. Locally, the request could work on a system subnet, but on mainnet, it won’t work on an application subnet. Which mainnet subnet were you targetting?

1 Like
3

Given that you can deploy your canister both locally and on mainnet, did you double check that you actually pass correctly the Gzip file path to Pocket-ic and not inadvertently the path to the Wasm?

Stupid feedback but, you never know…

1 Like
4

Given that you can deploy your canister both locally and on mainnet, did you double check that you actually pass correctly the Gzip file path to Pocket-ic and not inadvertently the path to the Wasm?

That could totally have happened! :joy: But not this time. The byte size specified in the message, 2,5 mb ca, is the compressed size. BoaEngine I believe take up a lot of that space.

I was under the impression the allowed WASM size for canisters had been raised quite significantly, back in January or there around. See here for instance:

Also, for testing, I tried installing my canister unzipped to ic, 9+ mb, that worked without issue.

https://a4gq6-oaaaa-aaaab-qaa4q-cai.raw.icp0.io/?id=mzakg-qaaaa-aaaal-qjesa-cai

@mraszyk am I misunderstanding something here?

2 Likes
5

If you use dfx to deploy your canister on mainnet, then dfx would chunk your WASM and upload the chunks in multiple update calls (using the so-called large WASM feature). PocketIC doesn’t do that yet which might be why you perceive a different behavior.

1 Like
6

Ah, thanks. Will PocketIC implement chunking in the future so larger canisters can be tested as well?

1 Like
7

Just to double check: are you using the PocketIc::install_canister library function in the Rust PocketIC library?

1 Like
8

Yup.

use candid::{decode_one, Principal};
use catts_engine::Recipe;
use pocket_ic::{PocketIc, WasmResult};
use std::fs;

const CANISTER_WASM: &str = "../../target/wasm32-wasi/release/catts_engine.wasm.gz";

fn setup() -> (PocketIc, Principal) {
    let pic = PocketIc::new();
    let canister = pic.create_canister();
    pic.add_cycles(canister, 2_000_000_000_000); // 2T Cycles
    let wasm = fs::read(CANISTER_WASM).expect("Wasm file not found, run 'dfx build'.");
    pic.install_canister(canister, wasm, vec![], None);
    (pic, canister)
}

#[test]
fn test_recipe_list() {
    let (pic, catts) = setup();

    let Ok(WasmResult::Reply(response)) =
        pic.query_call(catts, Principal::anonymous(), "recipe_list", vec![])
    else {
        panic!("Expected reply");
    };

    let result: Vec<Recipe> = decode_one(&response).unwrap();
    
    // do some assertions
}
1 Like
9

Some parts can of course be unit tested. But, all parts that require ic specific features would need to be mocked, which is quite messy. I am surprised not more devs have run into this. Maybe testing of canisters is not a big thing.

To begin with I’ll try replacing the JS runtime I use in the canister to see if I can squeeze size below limit. That was the plan anyway. Large wasm support further on would be fantastic though!

10

I’m optimistic that it’s easy to add it and will look into this soon.

1 Like