In summary, it is adding a new wasm_memory_limit
limit field to canister settings.
the foundation will also need to incorporate it into the JS library
@dfinity/ic-management
.
Thanks, I’ll update that.
Considering that creating a backup is a recommended action in case of an error, wouldn’t it be more prudent for the foundation to first propose the “Canister backup and restore” feature, which has been eagerly anticipated by everybody for a long time, before proposing this change?
I think wasm_memory_limit
is a strict improvement over the situation we have right now regardless of canister backup/restore. It gives the developer more control:
- if they want to wait for canister backup/restore, then they can set the limit to
4GiB
now and lower it when the backup/restore ships. - if they already have a canister-level backup/restore, then they are going to benefit from the limit.
- if the developer hasn’t read this post and is unaware of the limit, then they can increase the limit to
4GiB
after they see errors.
Regarding the last actionable item, are there any comprehensive guides or examples available that can help community developers in migrating their large GB data from heap to stable storage?
I am not aware of such a guide. I saw a presentation recently about migrating the NNS dapp from the heap to stable structures. I’ll ask the author if they can share the slides publicly or maybe even write a guide. The general idea is to do the migration incrementally.