I guess I don’t have to worry the acceptability of bumping this old topic.
Awesome new feature and very helpful!
While we are here, there are a number of ‘other’ hooks that would be very helpful and one topic that would be worth discussing here in regards to the work I’ve been doing on ICRC-105. ICRC-105 - Wasm History Management and Transaction Blocks · Issue #105 · dfinity/ICRC · GitHub
The ‘spirit’ of ICRC-105 is to give public utility canisters a spot in the ICRC-3 log to record any configuration, upgrade, or installation changes that may be relevant to the execution of the canister. The ideal ‘best-case’ scenario would be that given an ICRC-105 + ICRC-3 canister, the set of used wasms, properly recorded ICRC-3 block(proper being that they recorded all information relevant to the deterministic execution program/state changes) that one could reconstruct the state of the canister from the ICRC-3 log. This means we need to record any change to the canister the would affect how the code runs. Since you can write any code there may be a number of unknown unknowns that a dev would be responsible for, but it would be nice to take care of the known possible changes via canister life cycle events.
The obvious events would be
- Change of Controller(give me the new list)
- Change of canister settings(like compute_allocation, memory_allocation, freezing_threshold, reserved_cycles_limit, wasm_memory_limit, log_visibility (give me the new setting)
- A canister freeze(let this run once if my canister is frozen)
- A change of the environment variables(I understand this is under development) (let me enumerate the items or give them to me)
- A subnet change(when subnet migration is possible)(new subnet id)
- Edit: Canister Installed/upgraded (give me the new hash) - right now I have to do an timer+async call from my initializer and it delays and theoretically, something else could get called before I log the new hash…thus I have two blocks, one to record the install/upgraed and then a follow on to record the new hash.
One that is not so obvious would be something that fires if the version of the replica changes. I’m not sure what the process or workflow is there, but I would imagine that if a replica version is updated it might include code that could change the way a canister behaves(something like the cycle cost of certain operations or even system API level information). It may not be a great feature to have every canister on the subnet firing an event each time a new replica version starts up, but perhaps this could fire the first time that canister is called in the future?