Candid field names instead of hashes

It would be really nice if Candid encoded the actual plain text field names of records and variants instead of or in addition to the hashes, it makes reading errors and dealing with encoded Candid generally difficult. See here: Why do I output variable names as numeric values on the command line

For example, if I encode this Candid string: (variant { ok = true }) and then decode those bytes I get (variant { 24_860 = true }). I’m writing some tests and this is making things difficult for me.

1 Like

Fair point, but this is going to be a breaking change.

As for your example, is there a reason you don’t know the type when you are decoding the message?

1 Like

We’re testing general purpose encoding/decoding of Candid strings/blobs (we’ve provided this functionality in Azle through ic.candid_encode and ic.candid_decode), so I was hoping to just pass in a string, encode it, decode it, and get back an identical string. Works for everything except records/variants. I don’t know what people are going to use call_raw, notify_raw etc for, nor if Candid encode/decode of strings will be useful to them, but just bringing up that it’s making my tests more difficult than perhaps they need to be.

Also when trying to debug a Candid serialization/deserialization error in the command line, seeing all of the hashes is confusing.

so I was hoping to just pass in a string, encode it, decode it, and get back an identical string.

We don’t guarantee this roundtrip. Besides field names, other short hand can prevent you from getting identical string. For example, blob "a" becomes vec {97}; 1_000 becomes 1000.

Ideally, both encode and decode should take Candid types as an argument, so that you can also test for backward compatibility.


It would actually be cool to get a known hash canister that could return these and have dfx wire it up.

Seems like canlista could output this from their data pretty easily.(this wouldn’t really work for your tests but would be great for known services)

There are some caveats sure, but it’s working fine on most of the types I’m using. What doesn’t work as easily is the hashed names for records and variants, since it’s not as simple as adding a space or a colon with a number type.

If you are decoding with a type, you will get the field name back in the test as well.