Thread 'event.loop0' panicked at 'Expected always-serializable type; qed: Error("u128 is not supported", line: 0, column: 0)', src/libcore/result.rs:1165

[IPSE-TEAM]

Version: 2.0.0-401c373d-x86_64-macos

stack backtrace:
0: backtrace::backtrace::trace
1: backtrace::capture::Backtrace::new
2: sp_panic_handler::set::{{closure}}
3: std::panicking::rust_panic_with_hook
4: std::panicking::continue_panic_fmt
5: rust_begin_unwind
6: core::panicking::panic_fmt
7: core::result::unwrap_failed
8: <futures::future::map::Map<A,F> as futures::future::Future>::poll
9: <futures::future::map_err::MapErr<A,F> as futures::future::Future>::poll
10: <futures::future::either::Either<A,B> as futures::future::Future>::poll
11: <futures::future::lazy::Lazy<F,R> as futures::future::Future>::poll
12: futures::future::chain::Chain<A,B,C>::poll
13: <futures::future::then::Then<A,B,F> as futures::future::Future>::poll
14: <futures::future::map::Map<A,F> as futures::future::Future>::poll
15: <futures::future::either::Either<A,B> as futures::future::Future>::poll
16: <futures::future::map::Map<A,F> as futures::future::Future>::poll
17: <futures::future::select::Select<A,B> as futures::future::Future>::poll
18: <futures::future::map::Map<A,F> as futures::future::Future>::poll
19: <futures::future::map_err::MapErr<A,F> as futures::future::Future>::poll
20: futures::task_impl::std::set
21: std::panicking::try::do_call
22: __rust_maybe_catch_panic
23: tokio_threadpool::task::Task::run
24: tokio_threadpool::worker::Worker::run_task
25: tokio_threadpool::worker::Worker::run
26: tokio_reactor::with_default
27: tokio::runtime::threadpool::builder::Builder::build::{{closure}}
28: std::thread::local::LocalKey::with
29: std::thread::local::LocalKey::with
30: std::sys_common::backtrace::__rust_begin_short_backtrace
31: std::panicking::try::do_call
32: __rust_maybe_catch_panic
33: core::ops::function::FnOnce::call_once{{vtable.shim}}
34: <alloc::boxed::Box as core::ops::function::FnOnce>::call_once
35: std::sys::unix::thread::Thread::new::thread_start
36: _pthread_start

Thread 'event.loop0' panicked at 'Expected always-serializable type; qed: Error("u128 is not supported", line: 0, column: 0)', src/libcore/result.rs:1165

operate in the fronte,then the node is dead.

[arkpar]

Error messages seems to be coming from jsonrpc/derive @tomusdrw

[tomusdrw]

Yeah, it's the serde issue striking back. Are you using u128 for any of the custom numeric types (like block number for instance)?

[IPSE-TEAM]

https://github.com/paritytech/substrate/blob/master/bin/node/primitives/src/lib.rs#L41

just balance using u128 type,others instance did not using u128 type .

our project hub: https://github.com/TransactionX/TransX

you could try compile the binary,then the error will come.thx.@tomusdrw

[bkchr]

As @tomusdrw said, this is a bug in serde. We have created prs to fix it upstream, but still waiting for getting them merged.

[tomusdrw]

@IPSE-TEAM does it show up when calling a particular RPC?

[Dengjianping]

This problem happened to me. I customized a rpc method for my own runtime module. And I just wanted to return balance according to specified account. As a result, the same error ocurred while I used curl for calling rpc method.

Thread 'http.worker30' panicked at 'Expected always-serializable type; qed: Error("u128 is not supported", line: 0, column: 0)', src/libcore/result.rs:1188

rev = "8f4495886"

[wangjj9219]

This problem happened to me. I customized a rpc method for my own runtime module. And I just wanted to return balance according to specified account. As a result, the same error ocurred while I used curl for calling rpc method.

Thread 'http.worker30' panicked at 'Expected always-serializable type; qed: Error("u128 is not supported", line: 0, column: 0)', src/libcore/result.rs:1188

rev = "8f4495886"

also happened to me, I use struct to wrap the generic of u128, and impl serde::Deserialize and Serialize for the struct, It works.

[brenzi]

I got this in a custom rpc too, but with i128. Any update on this?
using jsonrpc-derive = "18.0.0"

[bkchr]

@brenzi this is because serde has problems with these types. In the transaction payment for example we convert the type to a string before putting it into Json.