ICDevs.org Voting Incident Report and Stable API Discussion

Sorry, for the later response. Yes, this was a Motoko bug and is fixed in 0.10.1 (released 2 weeks ago).

2 Likes

@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.

1 Like

I loaded in the playground and the old types seemed to work, so Iā€™m guessing it was the Motoko version.

1 Like