`install_code` api results not known from response

[linnefromice]

If you use dfx, I will see caution or confirm as follows.

# When same wasm module
% dfx canister install backend_by_cli --mode=upgrade
Module hash 9b82b550f81d8e064abdcc6f70ab7aabae42840fa528deb9b907ed1e821bdfd8 is already installed.

# When breaking changes
% dfx canister install backend --mode=upgrade
WARNING!
Candid interface compatibility check failed for canister 'backend'.
You are making a BREAKING change. Other canisters or frontend clients relying on your canister may stop working.

Even in the above situation, calling install_code (mode=upgrade) from canister returns variant { Ok } in all cases. Is it possible to know the actual result (ex: module hash after install) from the response? Or if Ok, does it mean that the module is installed (even if it is the same module)?

[sesi200]

The warning you see with dfx is purely based on a client-side check. That check does not affect the ability to upgrade code at all, but it can affect users of your canister, which is why we warn about it.

Similar to the interface compatibility check, not installing the same code twice is also a client-side optimisation by dfx that you can override using --upgrade-unchanged.

install_code doesn't care about such 'details'. It's the raw system API (well... a thin wrapper thereof) that will always try to install the code you hand it. And if you get Ok back, it means that (if present) pre_upgrade ran, the new code was installed successfully, and that (if present) post_upgrade completed as well. Assuming no interference from parallel upgrade calls, if you get Ok back, then the currently installed module is the one you just called install_code with