Sorry, for the later response. Yes, this was a Motoko bug and is fixed in 0.10.1 (released 2 weeks ago).
@msumme This happned again about 11 days ago:
[0. 2024-08-30T14:36:28.663718978Z]: [TRAP]: IDL error: byte tag not 0 or 1
[1. 2024-09-10T15:59:29.223433295Z]: [TRAP]: IDL error: byte tag not 0 or 1
Iām guessing this is when the new Types went out? Iām trying to figure out what I need to do so that even when there are new types Iām not getting an error.
You can see the diff between the types I had and the types I just pulled from the dashboard here: Updated types Ā· icdevsorg/eventually_reject@fdbab79 Ā· GitHub
Updating the types made it work. It doesnāt seem like this should be the case. For backwards compatibility Iād assume that any update values would be able to be set to nullā¦Iām not accessing anything but deadline_timestamp_seconds
and thisItem.ballots
and thisBallot.vote.
Does the trap happen when decoding the response from list_proposals
?
Assuming so:
If I use the governance.did
file from last September (here), and do:
git checkout 8abe5f41e0ff221a1165669ef8b6be90d6574b3e
dfx canister --ic call rrkah-fqaaa-aaaaa-aaaaq-cai list_proposals \
'( record { include_reward_status = vec {1}; omit_large_fields = opt true; before_proposal = null; limit = 100 : nat32; exclude_topic = vec {2}; include_all_manage_neuron_proposals = opt false; include_status = vec {0;1;2;3;4}; }, )' \
--candid rs/nns/governance/canister/governance.did
The response seems to decode fine.
In addition, simply querying the latest 100 proposals also works fine (just in case the problematic proposal is already settled):
dfx canister --ic call rrkah-fqaaa-aaaaa-aaaaq-cai list_proposals '( record { include_reward_status = vec {}; omit_large_fields = null; before_proposal = null; limit = 100 : nat32; exclude_topic = vec {}; include_all_manage_neuron_proposals = null; include_status = vec {}; }, )' --candid rs/nns/governance/canister/governance.did
It would be nice to confirm where the trap happens before digging deeper (e.g. reproducing in motoko and either bisect or see if there is more detailed error).
I think it must.
The motoko code that was causing the trap can be found at this commit: Updating Governance Types Ā· icdevsorg/eventually_reject@1d4d74d Ā· GitHub
The trap first occurred on 8/30 and killed my timer. I tried again today and it failed as well(see above from canister log (h/t canister log team that helps me confirm something previously unconfirmable and probably saved me 3 hours), so I donāt think it was an issue with a problematic proposalā¦I think it is an issue decoding the general structure from inside of motoko.
I believe this was dfx version 0.14.2, so whatever Motoko compiler was active then.
I will ask the sdk and candid teams if we can figure this out.
Have you already tried updating dfx to the latest and rebuilding with the old types?
From looking into this, it looks like dfx 0.14.2 ships with motoko 0.9.3, which as far as I can tell does not have the fix.
That is likely the cause. Could you try compiling the canister with updated dfx and old types and see if you still get the error? That would confirm that this is the cause.
I loaded in the playground and the old types seemed to work, so Iām guessing it was the Motoko version.