It was correct when deployed to the mainnet for the first time, but after adding new functions
When deploying using dfx deploy --network ic, the following error will be prompted
Error: Failed while trying to deploy canisters.
Caused by: Failed while trying to deploy canisters.
Failed while trying to install all canisters.
Failed to install wasm module to canister 'counter'.
Failed during wasm installation call: The replica returned a replica error: reject code CanisterError, reject message Canister p3ava-uiaaa-aaaal-qcira-cai trapped explicitly: IDL error: principal too long, error code None
Use dfx canister --network=ic install counter --mode=upgrade
Will also report an error
Error: Failed to install wasm module to canister 'counter'.
Caused by: Failed to install wasm module to canister 'counter'.
Failed during wasm installation call: The replica returned a replica error: reject code CanisterError, reject message Canister p3avo-uiaaa-aaaal-qcira-cai trapped explicitly: IDL error: principal too long, error code None
It is normal to use dfx canister --network=ic install counter --mode=reinstall, but the user’s data will be cleared. I don’t know how to solve this problem, which makes my application unable to upgrade.
@claudio@Manu Can anyone solve this problem? This is a very fatal problem, which makes it impossible to upgrade the application, which is very unfriendly to users.
The error should only occur if Candid or stable variable decoding encounters an (illega) principal with > 29 bytes.
Are you constructing principals or Candid blobs manually somewhere?
import Principal "mo:base/Principal";
actor this {
stable var self = Principal.fromBlob("012345678901234567890123456789");
}
If you deploy the code, it deploys, fine, but if you then try to upgrade (without any code change) it produces the error you report.
One problem here is that Motoko is (incorrectly or at least unsafely) letting you construct a principal with >29 bytes. I’m surprised we don’t prevent that. Are you doing any manual construction of principals like this, using Principal.fromBlob()?
Yes, I tested it, and even when my updated code only contains “actor {}”, it still prompts an error. So, is the problem actually with the deployed code
Thank you for your help.
I seem to have found the problem. Account.accountIdentifier(Principal.fromActor(this), Account.principalToSubaccount(caller)).
It seems that Principal with different lengths are generated. If they are stored in stable, the length will be incorrect.
But if there is already a large user base, it seems that the data has to be cleared to upgrade. Can this problem be verified during the deploy stage?
It turns out that the Candid specification doesn’t limit the size of Candid principals but both the Rust and Motoko implementations do on deserialization , because IC principals are less than 29 bytes.
For consistency we should either make Principal.fromBlob trap if the blob is too long, and never allow the construction of large principals, or
allow longer Motoko Principals for internal use and Candid and rely on the IC limit checks when they are passed to the IC via Candid.
How important is your data at the moment? Can you afford to lose it because it is just test code?
If so, I suggest we consider going for the first option and restrict Principal.fromBlob to trap on large Blobs, and you use your own implementation of that until it is fixed in base. But that is a breaking change for everyone.
If not, maybe we could modify Motoko to not enforce the length of Candid principals on deserialization, allowing you to upgrade, perhaps using a special compiler flag to allow large principals.
Where does this Account type come from, btw? Are accounts supposed to fit in principals or would it be better to just use Blob anyway.
