Feature Request: Provide easier access to canister_status

Developers
1

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.

Thoughts?

1 Like
2

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.

3 Likes
3

Yes, that would be perfect. That wouldn’t require a change to any existing API as well.
:metal:

4

I run the proposal internally through the teams that are affected: we’ll try to get this done soon.

1 Like
5

Can you also do the same for updatesettings?

6

Wasn’t a variant of this proposed under this RFC? I think that proposal never got much traction for whatever reason.

1 Like
7

The scope of that RFC, looks quite large as compared to the ask here.

This thread is just about making the canister_status of a canister available to itself.

It can then choose if it wants to expose it to the outside world using a separate function implemented on itself.

But yeah, standards are always a good thing. :slight_smile:

8

Makes sense. We’ll add that to the list.

9

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.

1 Like
10

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.

We may revisit this point in the future.

2 Likes
11

Thank you. Will keep an eye out for the proposal :slight_smile: