The canister_status when queried by a canister for itself is rejected. This is because this call is only allowed for principals that are a controller for this canister. However, this behavior is unintuitive and restrictive.
Please consider enabling one of the following:
Making this data publicly callable instead of requiring a controller to call
Adding the canister’s principal to the list of controllers by default on canister creation. That way the canister can choose to expose this on itself rather than the management canister making this public
The reasons for this ask are:
Being able to query one’s own controllers and using them for access control (admin access) to certain methods being exposed
Being able to query one’s own memory usage to determine if nearing memory usage limits and need to create additional canisters. The current landscape of things require having to track and update this value internally to be able to do this
Adding canisters to a cycle monitoring canister or external service or even to an NNS Dapp wallet and being able to view the cycle balance to decide if the canister requires a top up or not without having to add the monitor’s principal as a controller
The above is still manageable when you have a single canister architecture but is absolutely required when building a multi canister architecture using dynamically created canisters.
How about always allow the canister_status call from the canister itself, without explicitly adding it to its own controller list? Would that suffice? It doesn’t deal with the first bullet point in the reasons list, but I think it suffices for the remaining two.
This change would be rather simple to implement.
As @saikatdas0790 said that RFC is much bigger in scope – we’re still tracking it and plan to improve on that side. The changes required here are significantly smaller so we’ll try to move fast on those.
Good news: the next replica version will allow a canister to read its own status.
However, due to security concerns, we have not implemented the analogous relaxation that would allow a canister to update its settings. This change would make auditing canisters somewhat more involved since a canister which appears to have no controller may at some later point change its controller list.