Deserializing u128 errors when inside an untagged enum

[uint]

Minimal reproducible example below. Note that the second you change u128 -> u64, the test passes.

#[derive(serde::Serialize, serde::Deserialize)]
#[serde(rename_all = "snake_case", untagged)]
enum ExecuteMsg {
    Interface(Interface),
}

#[derive(serde::Serialize, serde::Deserialize)]
#[serde(rename_all = "snake_case")]
enum Interface {
    IncreaseAllowance { amount: u128 },
}

#[test]
fn foo() {
    let foo = ExecuteMsg::Interface(Interface::IncreaseAllowance { amount: 777 });

    let foo_ser = serde_json_wasm::to_string(&foo).unwrap();

    let wrapper_de: ExecuteMsg = serde_json_wasm::from_str(&foo_ser).unwrap();
}

[uint]

At a glance, this doesn't seem easily solvable. @hashedone any ideas?

[webmaster128]

The error we are getting with the above test is

panicked at 'called Result::unwrap() on an Err value: Custom("data did not match any variant of untagged enum ExecuteMsg")', src/lib.rs:226:58

which is generated by serde: https://github.com/serde-rs/serde/blob/v1.0.147/serde_derive/src/de.rs#L1667-L1677. But I don't understand what those #attempts are and why this is failing.

The raw JSON is

{"increase_allowance":{"amount":"777"}}

which looks solid.

[uint]

@webmaster128 In my investigation, I figured that when deserializing into an untagged enum serde first has to call deserialize_any to translate the input JSON into serde's representation. Then serde analyzes that to figure out which enum variant it matches. Or something along those lines.

The problem is there's no logic for deserialize_any to figure "this string I just found could be a string or it could be a u128".

[uint]

I looked a bit deeper into serde macros and this might actually be due to serde's Content type (there's also this).

[webmaster128]

I wonder if #54 solves this issue

[chipshort]

This is not fixed by #54.
It seems to be a serde bug. I get the same behaviour with serde_json.

While digging into it, I found these issues (and a few others that probably have the same root cause):
serde-rs/json#740
serde-rs/serde#1183