You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor: Consolidate how system state modifications are extracted from the System API (dfinity#3706)
Currently, there are two similar functions in the `SystemApiImpl` to
extract system state modifications. One of them
`take_system_state_modifications` is used in the sandbox when preparing
the state changes to be transmitted back to the replica. Then, the
replica after deserializing the result that it receives from the sandbox
calls `into_system_state_changes` on the reconstructed `system_api` to
extract the changes again.
In a recent [PR](dfinity#363),
`into_system_state_modifications` was changed (to make it more clear
which changes are relevant per message type) but
`take_system_state_modifications` wasn't. This works correctly because
`into_system_state_modifications` is the last one that's called before
applying the state changes back to the canister state. However, it's
also a very clear example of how the code can easily diverge and go
unnoticed, potentially with more severe implications in the future.
This PR proposes to use one function which seems to provide the usual
benefits of consistent way of applying the changes and "having one way"
of doing the same task. We keep `take_system_state_modifications` (this
allows us to get rid of some `clone`s but more importantly it's needed
in the sandbox, see comment in the existing code) and change the call
sites respectively.
0 commit comments