From 709d5b4938015075d52854a46f664fa5bf2d9207 Mon Sep 17 00:00:00 2001 From: Martin Raszyk Date: Fri, 19 Dec 2025 10:22:37 +0100 Subject: [PATCH 1/2] chore: mention memory matrix tests in mgmt canister contribution guideline --- rs/execution_environment/Contributing.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rs/execution_environment/Contributing.md b/rs/execution_environment/Contributing.md index 88a9c6e932ae..b746a9d63b02 100644 --- a/rs/execution_environment/Contributing.md +++ b/rs/execution_environment/Contributing.md @@ -41,6 +41,7 @@ The public API of the Management Canister is defined in Candid. Candid is design 8. Write tests to cover the new or updated functionality: - Use the `ExecutionTest` framework by default. - Use the `StateMachine` framework if the feature involves inter-canister calls, canister HTTPS outcalls, threshold signatures, or checkpointing. These require mocked Consensus layer outputs or a full state manager. + - Make sure to add new scenarios to `rs/execution_environment/tests/memory_matrix.rs` if your change introduces new code paths dealing with canister memory usage/allocation. 9. Once the *Interface Specification* change has been agreed on, the public Management Canister [types](https://crates.io/crates/ic-management-canister-types), [Motoko](https://github.com/dfinity/motoko), and [Rust CDK](https://github.com/dfinity/cdk-rs) can be updated to use the new API on a feature branch. Coordinate with *@eng-sdk* and *@eng-motoko* as needed. The new functionality is enabled for testing in PocketIC (on a PocketIC instance created with `enable_beta_features` set) by enabling the corresponding feature flags in `rs/pocket_ic_server/src/beta_features.rs`. From aa08381d5bbc564b8fa40735a5eeacba32390d69 Mon Sep 17 00:00:00 2001 From: Martin Raszyk Date: Fri, 19 Dec 2025 10:35:05 +0100 Subject: [PATCH 2/2] update doc comment for memory matrix tests --- rs/execution_environment/tests/memory_matrix.rs | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/rs/execution_environment/tests/memory_matrix.rs b/rs/execution_environment/tests/memory_matrix.rs index 1d60463c34eb..0783fc597622 100644 --- a/rs/execution_environment/tests/memory_matrix.rs +++ b/rs/execution_environment/tests/memory_matrix.rs @@ -7,17 +7,28 @@ It defines multiple *scenarios* and their expectations in terms of memory usage and performs multiple *runs* of every scenarios with various initial parameters. The runs ensure the following properties for every scenario: -- subnet available memory is updated properly in both successful and failed executions; +- reserved cycles and subnet available memory are updated properly in both successful and failed executions; - the execution fails if the subnet memory capacity would be exceeded; - the execution fails if the reserved cycles limit would be exceeded; - the execution fails if the canister would become frozen; - the execution fails if the canister does not have sufficient balance to reserve storage cycles; - the execution does not allocate additional memory for canisters with memory allocation. -The scenarios cover the following: +Every memory matrix test has the following components: +- a "setup" function takes `&mut ExecutionTest` and `CanisterId` of an empty canister in that `ExecutionTest`, + performs a setup of that canister, and returns arbitrary data of choice (could also be `()` if no data are needed) + that are relayed to the "operation" function; +- an "operation" function takes `&mut ExecutionTest`, `CanisterId` of the canister set up before, and + the data produced by the "setup" function before; +- an instance of `ScenarioParams` also containing `Scenario` and `MemoryUsageChange` describing + the kind of scenario and its expectations in terms of canister memory usage change; +- an actual invokation of the matrix test suite implemented by the function `test_memory_suite`. + +The existing scenarios cover the following: - growing WASM/stable memory in canister (update) entry point; - growing WASM/stable memory in canister reply/cleanup callback; - taking a canister snapshot (both growing and shrinking canister memory usage); +- taking a canister snapshot and uninstalling code atomically; - replacing a canister snapshot by a snapshot of the same size; - loading a canister snapshot (both growing and shrinking canister memory usage); - deleting a canister snapshot;