Custom(No more values on the wire, the expected type nat64 is not opt, reserved or null)

Developers
1

I’m testing out init arguments in Azle, and all of the sudden I can’t deploy canisters locally with parameters. I am using dfx 0.9.3 and I’ve been trying to follow the advice here: Upgrade canister on ic with new dfx version - #7 by ericswanson but I keep the following error every time I try to deploy with an argument:

Installing canisters...
Upgrading code for canister init, with canister_id rrkah-fqaaa-aaaaa-aaaaq-cai
Error: The Replica returned an error: code 5, message: "Canister rrkah-fqaaa-aaaaa-aaaaq-cai trapped explicitly: Custom(No more values on the wire, the expected type nat64 is not opt, reserved or null)"

The code looks like this, just a normal init with a simple argument:

import {
    Init,
    ic,
    nat64
} from 'azle';

export function init(nat64: nat64): Init {
    ic.print('nat64', nat64);
}
2

Did you update the did file to include the init arg types and deploy with dfx deploy --argument "(42)"?

1 Like
3

Ah, I see the service needs the parameters. I will try that, thanks!

4

This worked! Thank you

5

Hi @chenyan, I use the following to generate my candid bindings:
image

But it looks like it does not update when canister init arguments are used. Thoughts?

Also, I’m running into the same issue as @lastmjs

Do I just need to specify the init argument as a type or is there any additional changes that need to be made to the service entry in my candid file?

6

Hi @lastmjs

In case you have any opinions on how to resolve the above, would be grateful for your inputs :slight_smile:

7

Does the generated did contain the init arg type? For example service : (InitArgs) -> { method: () -> () }

If not, you may need to use #[candid_method(init)] for the init function.

1 Like
8

Yep, that init attribute was exactly what I was missing. That did it. Thank you

1 Like
9

@chenyan
Another additional question.

Since the canister init requires args, so dfx canister install --mode install/reinstall will require us to pass arguments.

Why does --mode upgrade also require the argument? Since during upgrade only pre_upgrade and post_upgrade are run?

I see this when I run dfx canister install <canister_name> --mode upgrade for the canister with the argument:
image

10

postupgrade also takes arguments. In Motoko, we assume this is the same type as the init args in actor class. In Rust, I think we made the same assumption, but theoretically it can take a different type. So for upgrade, you need to provide the init arg, and the behavior is specified in the post-upgrade function, not the init function.

2 Likes