Issue: Asset Canister Can't Be Upgraded via SNS proposal

We believe that we’ve found a critical issue in the SNS preparation documentation. We have an asset canister that is under control of the SNS, but we are unable to upgrade this asset canister for the following reasons:

  1. The SNS documentation is not clear that the SNS governance canister must be granted the ManagePermission permission of all asset canisters before an SNS.
  2. Without this ManagePermission permission, the SNS governance canister cannot change the permissions of asset canisters.
  3. All SNS proposals to call a generic function are calling from the SNS governance canister. This seems like a major flaw because most functions require the controller of the canister to call them. And the controller is always the SNS root canister, not the SNS governance canister. So why is the SNS governance canister making the calls to generic functions?
  4. Since the SNS governance canister is not a controller of the asset canister (only the SNS root canister is), the SNS governance canister cannot call grant_permissions to change permissions. Since the asset canister permissions can’t be changed, the asset canister cannot be upgraded.

Is there a way to make a proposal that calls a generic function from the SNS root canister instead of the governance canister?
Otherwise, we may have to de-register our asset canisters from SNS, configure them with the correct permissions, and re-register them."

3 Likes

Correct, documentation is insufficient for asset canisters. We’ll fix it.

No, no way to do this.

Your idea to de- and re-register works for sure. The other idea I have is that if you didn’t change permissions at all then the original identity could still have the permissions to add SNS governance and remove itself from the authorised list

I assume that only controller can change the permissions ? Or the principal who has ManagePermissions permit.
In our asset canister, we only have a single permission and that is of Commit for our dev principal.
Can we still change our asset canister permissions?

That’s correct

No, in that case not. But you can still make changes to the assets. I suggest you change that to Prepare as well when you then modify the permissions

2 Likes

hey, i have one more question regarding custom functions.
So we have a parent canister which has several child canisters. To push wasm update to child canister we use parent’s custom function. We already registered custom function upgrade_wasm in the parent canister, it does have payload validate function as well which returns {#Ok: Text; #Err : Text} and upgrade_wasm does not returns anything.
But on executing upgrade_wasm via proposal it failed, though our validate function returning #Ok().
AFAIK we have done all required steps for execution, so what can be the potential reason of this failure?
Only thing I know of can be that we put a assert in upgrade_wasm function, so that only our SNS governance canister can invoke that method, can this be the reason?
Here are methods :
validate_wasm : (int) → (variant {Ok:text; Err:text})
upgrade_wasm : () → ()
Should our endpoints look like this?
validate_wasm : (int) → (variant {Ok:text; Err:text})
upgrade_wasm : (int) → ()
Can this be the reason of failure?

Looks fine to me. I would have expected for the functions to take a blob, but you probably have a list of wasms stored and are passing the index. Anyways, that shouldn’t affect if it works or not.

That’s possible. Can you double- and triple-check if the principal is correct? Another idea to debug is to write a log during the call that you can then later read out. But please don’t panic in the function, otherwise writing the log gets rolled back

So this is incorrect?
If we have our endpoints like this, execution will fail, right?

Right, sorry, I didn’t read carefully enough.

Correct, the two functions have to take the same arguments. validate is supposed to validate if the supplied argument can be a valid argument to the upgrade function. If not even the types match up it’s not possible for it to be a valid payload

1 Like

Hi, @h1teshtr1path1 @Severin

We encountered the same issue, and it seems the problem has not been resolved.

I’ve noticed that ICLighthouse also faced this problem, as seen in their proposals 68 and 71. They are currently trying to resolve this issue by deregistering the asset canister, configuring the permissions, and then re-registering it, as seen in proposal 104.

1 Like

If you upgrade the asset canister you can pass it a new set of permission lists, see here. With that you don’t need to de- and re-register anymore

quill sns make-upgrade-canister-proposal does not support canister_upgrade_arg :joy:

1 Like

Oops… Yeah, that makes it difficult to submit :laughing: I’ll bring it up with the team… (Note to self: ticket)

1 Like