šŸ¤— *PocketIC*: Fast and versatile Canister Testing in Rust and Python

Developers
41

Hi, I am facing an issue while deploying Azle canisters in PocketIC.

Failed to submit ingress message: Request 0xe0f1ba98a0f5d58ba935b66d48dc348e216c8d1ca31010bb2bac95a4d9bf087a is too large. Message byte size 7278992 is larger than the max allowed 3670016.

I checked my canisterā€™s wasm file. Itā€™s indeed around 7MB. So is there any solution for this?
I tried optimizing the Azle binary but canā€™t get it to go less than 3MB.

42

Hi @sudoshreyansh, you could try zipping your Wasm and then uploading it.

1 Like
43

Rust crate pocket-ic 2.2.0 is not compiling with candid ^0.10 and ic_cdk ^0.13. (due to pocket-ic depending a specific version of candid_derive)

The PocketIC Server is at 3.0.1. Should these versions follow each other?

I tried downgrading some deps but still could not find a version match for my workspace.

44

This pinned dependency will be relaxed in the next release. Until then, please try to use an older version of ic_cdk.
Apologies for the situation, I know it is not ideal. The root cause is a breaking change between ic_cdk 0.12.0 and 0.12.1 (which I did not expect in a version change in the least significant digit).

The library 2.2.0 is compatible with server 3.0.1. The reason they diverge is that the serverā€™s API has had breaking changes, but the library did not have to change its user-facing API to be able to use the new server.

1 Like
45

Hi ufoscout,

Some thoughts on offering an asynchronous API as well as the synchronous one:

This is like a common problem in the rust ecosystem (here is just one recent example), and the language currently makes it difficult to solve without either duplicating code or making additional assumptions/demands on the consumer of the library. I can imagine that in some domains, a library core could be implemented in a pure fashion, and the IO could be its own, user-specified layer. But this is not how PocketIC is currently written, and it is (after some experimentation) not clear to me how to make it so.

Apart from making things consistent for e.g. your framework, there also seems to be little benefit of asynchronicity in this instance, because calls to a PocketIC instance within a single test cannot be interleaved anyway*, making them in essence blocking calls (even if implemented via polling, as in the new PocketIC release).

If you think there is some low-hanging fruit I am not seeing that would enable your use case, please let me know.

*) In version 4 of the PocketIC server (and Rust library v3.1), PocketIC instances also expose the replicaā€™s API, which is the IC HTTP interface as specified and used on mainnet. Of course, that does not directly address your problem, as this asynchronous API is not compatible with the PocketICā€™s tick-based approach. But it is a asynchronous alternative to the blocking PocketIC API.
There are also two new methods the server exposes, which enable interleaving messages, see the HowTo in the links above, which might be interesting for your use case if you decide to implement your own asynchronous code to communicate with the server.