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
11

@mraszyk

Edited

Any updates on this? I’m running into this with pic.js 10.0…my wasm zipped is just over the limit. It has another actor that it deploys. I can pull that out from a reference and upload the bytes into the canister after deploy, but this will extend the setup time and is just generally annoying to have to do.

I see that it was added in 5.0.0, but I’m guessing that pic may not be using it. I’ll investigate.

12

Looks like we need a function to encode the install_chunked_code_args in pic-js/packages/pic/src/management-canister.ts at main · hadronous/pic-js · GitHub and and some smarts in pic-js/packages/pic/src/pocket-ic.ts at b5f394a3d857ea5017727f96977b55cba54bddcc · hadronous/pic-js · GitHub to look at the size and call install_chunked_code instead.

I’m curious what the store_canister is/does and what the sender_canister_version might need to be.

13
  • the store_canister is the canister ID of the canister that hosts the chunks (it can be the same canister as the installed canister or a different canister on the same subnet)
  • the sender_canister_version must not be set for ingress message (it could only be set for inter-canister calls as the sender’s canister version returned by the ic0.canister_version system API before making the inter-canister call)