owner api not working

[inb0x]

using latest v5.0.2, commands sent to /v3/owner with encrypted_request_v3 cause a panic message and no data is returned. node_height request causes this:

20210112 21:02:45.303 ERROR grin_util::logger -
thread 'unnamed' panicked at 'called Result::unwrap() on an Err value: "PoisonError { inner: .. }"': impls/src/client_utils/client.rs:349 0: grin_util::logger::send_panic_to_log::{{closure}}
1: std::panicking::rust_panic_with_hook
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:581
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:484
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153
4: rust_begin_unwind
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
5: core::panicking::panic_fmt
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
6: core::option::expect_none_failed
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/option.rs:1234
7: std::sys_common::backtrace::__rust_begin_short_backtrace
8: core::ops::function::FnOnce::call_once{{vtable.shim}}
9: <alloc::boxed::Box as core::ops::function::FnOnce>::call_once
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/boxed.rs:1042
<alloc::boxed::Box as core::ops::function::FnOnce>::call_once
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/boxed.rs:1042
std::sys::unix::thread::Thread::new::thread_start
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys/unix/thread.rs:87
10: start_thread
11: __clone

Thread 'unnamed' panicked with message:
"called Result::unwrap() on an Err value: "PoisonError { inner: .. }""
20210112 21:02:45.323 ERROR grin_util::logger -
thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: Any': impls/src/client_utils/client.rs:351 0: grin_util::logger::send_panic_to_log::{{closure}}
1: std::panicking::rust_panic_with_hook
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:581
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:484
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153
4: rust_begin_unwind
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
5: core::panicking::panic_fmt
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/panicking.rs:85
6: core::option::expect_none_failed
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/option.rs:1234
7: grin_wallet_impls::client_utils::client::Client::send_request
8: grin_wallet_impls::client_utils::client::Client::post
9: <grin_wallet_impls::node_clients::http::HTTPNodeClient as grin_wallet_libwallet::types::NodeClient>::get_chain_tip
10: grin_wallet_libwallet::api_impl::owner::node_height
11: grin_wallet_api::owner::Owner<L,C,K>::node_height
12: <grin_wallet_api::owner::Owner<L,C,K> as grin_wallet_api::owner_rpc::OwnerRpc>::node_height
13: ::handle
14: easy_jsonrpc_mw::handle_call
15: easy_jsonrpc_mw::handle_parsed_request
16: easy_jsonrpc_mw::Handler::handle_request
17: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
18: <hyper::proto::h1::dispatch::Server<S,hyper::body::body::Body> as hyper::proto::h1::dispatch::Dispatch>::poll_msg
19: hyper::proto::h1::dispatch::Dispatcher<D,Bs,I,T>::poll_catch
20: <hyper::server::conn::upgrades::UpgradeableConnection<I,S,E> as core::future::future::Future>::poll
21: <hyper::server::conn::spawn_all::NewSvcTask<I,N,S,E,W> as core::future::future::Future>::poll
22: <std::panic::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once
23: tokio::runtime::task::raw::poll
24: std::thread::local::LocalKey::with
25: tokio::runtime::thread_pool::worker::Context::run_task
26: tokio::runtime::thread_pool::worker::Context::run
27: tokio::macros::scoped_tls::ScopedKey::set
28: tokio::runtime::thread_pool::worker::run
29: tokio::loom::std::unsafe_cell::UnsafeCell::with_mut
30: tokio::runtime::task::core::Core<T,S>::poll
31: <std::panic::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once
32: tokio::runtime::task::harness::Harness<T,S>::poll
33: tokio::runtime::blocking::pool::Inner::run
34: tokio::runtime::context::enter
35: std::sys_common::backtrace::__rust_begin_short_backtrace
36: core::ops::function::FnOnce::call_once{{vtable.shim}}
37: <alloc::boxed::Box as core::ops::function::FnOnce>::call_once
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/boxed.rs:1042
<alloc::boxed::Box as core::ops::function::FnOnce>::call_once
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/boxed.rs:1042
std::sys::unix::thread::Thread::new::thread_start
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys/unix/thread.rs:87
38: start_thread
39: __clone

Thread 'tokio-runtime-worker' panicked with message:
"called Result::unwrap() on an Err value: Any"

[quentinlesceller]

Cannot reproduce on v5.0.2. Probably an error with the encryption scheme I'm guessing?
Can you copy paste your client code?

[quentinlesceller]

NB: probably unrelated but this is missing from master 2160813.

[inb0x]

here is an example that causes crash, V4.0 works fine

{"jsonrpc":"2.0","method":"init_secure_api","params":{"ecdh_pubkey":"0420d408f667677440ab836fb673747671344b3cb127bbacfae598d2b36e504e6b079693186b140f177a3d4c206925af049968d0970e0587a2c6b60d8d728f6c8e"},"id":0}{
"id": 0,
"jsonrpc": "2.0",
"result": {
"Ok": "027e2f56e072ebbc3122302400a745fe6b15fce50a10f2efd7c2992ebb0c923299"
}
}{"jsonrpc":"2.0","method":"retrieve_summary_info","params":{"token":null,"refresh_from_node":true,"minimum_confirmations":1},"id":0}{"jsonrpc":"2.0","method":"encrypted_request_v3","params":{"nonce":"68e37c67581db176a39be504","body_enc":"hboednNCb8sp2eK3rzO9IXMfHAG2c4lySRkP3T4+Hv0zSQISXmQe10f4kgh2I9lqx2liba+Lz/wMFOUx3lF+0zOUxIlNLi1vCrsiGRIzHWzbnlY0DwIEFXnGsKeKqEiUOpPVShFp9MKhD93BohdFvOuGS4bWN6QkBUENwqUbjQzRCr8CWt/1nQVlaoTRhRe5uZPWyw=="},"id":0}

[quentinlesceller]

Can you run manually grin-wallet info and let me know if the wallet can reach the node.

I'm guessing this is your issue here. I have ran several additional tests and I do not find any issue with the grin-wallet owner API.

[bladedoyle]

Another way to test Quentins theory is to use "refresh_from_node":false in the request and see of that works or not.

[bladedoyle]

Is it possible that you are neglecting to first call "open_wallet" and get a token?
I see that you are passing "token":null in the request.
When I test calling retrieve_summary_info without first calling open_wallet I do see threads in wallet owner_api crash, and after that its necessary to restart the owner_api for it to function again

[inb0x]

grin-wallet info works: (removed amounts)

Password:
20210114 00:33:10.808 WARN grin_wallet_libwallet::api_impl::owner_updater - Scanning - 0% complete
20210114 00:33:10.894 WARN grin_wallet_libwallet::api_impl::owner_updater - Scanning - 99% complete
20210114 00:33:10.903 WARN grin_wallet_libwallet::api_impl::owner_updater - Scanning - 99% complete
20210114 00:33:10.941 WARN grin_wallet_libwallet::api_impl::owner_updater - Scanning Complete

____ Wallet Summary Info - Account 'default' as of height 1045488 ____

 Confirmed Total                  | ????
 Awaiting Confirmation (< 10)     | ????
 Awaiting Finalization            | ?????
 Locked by previous transaction   | ????
 -------------------------------- | -------------
 Currently Spendable              | ???

Command 'info' completed successfully

here is the panic shown by grin-wallet owner when running retrieve_summary_info command referenced above:

thread 'tokio-runtime-worker' panicked at 'Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.': .cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/tokio-0.2.24/src/runtime/enter.rs:38   0: grin_util::logger::send_panic_to_log::{{closure}}
   1: std::panicking::rust_panic_with_hook
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/panicking.rs:530:17
   2: std::panicking::begin_panic
   3: tokio::runtime::enter::enter
   4: tokio::runtime::thread_pool::ThreadPool::block_on
   5: tokio::runtime::context::enter
   6: <grin_wallet_impls::node_clients::http::HTTPNodeClient as grin_wallet_libwallet::types::NodeClient>::get_outputs_from_node
   7: grin_wallet_libwallet::internal::updater::refresh_output_state
   8: grin_wallet_libwallet::internal::updater::refresh_outputs
   9: grin_wallet_libwallet::api_impl::owner::update_outputs
  10: grin_wallet_libwallet::api_impl::owner::update_wallet_state
  11: grin_wallet_libwallet::api_impl::owner::retrieve_summary_info
  12: grin_wallet_api::owner::Owner<L,C,K>::retrieve_summary_info
  13: <grin_wallet_api::owner::Owner<L,C,K> as grin_wallet_api::owner_rpc::OwnerRpc>::retrieve_summary_info
  14: <dyn grin_wallet_api::owner_rpc::OwnerRpc as easy_jsonrpc_mw::Handler>::handle
  15: easy_jsonrpc_mw::handle_call
  16: easy_jsonrpc_mw::handle_parsed_request
  17: easy_jsonrpc_mw::Handler::handle_request
  18: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  19: <hyper::proto::h1::dispatch::Server<S,hyper::body::body::Body> as hyper::proto::h1::dispatch::Dispatch>::poll_msg
  20: hyper::proto::h1::dispatch::Dispatcher<D,Bs,I,T>::poll_inner
  21: <hyper::server::conn::upgrades::UpgradeableConnection<I,S,E> as core::future::future::Future>::poll
  22: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
  23: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  24: tokio::runtime::task::raw::poll
  25: std::thread::local::LocalKey<T>::with
  26: tokio::runtime::thread_pool::worker::Context::run_task
  27: tokio::runtime::thread_pool::worker::Context::run
  28: tokio::macros::scoped_tls::ScopedKey<T>::set
  29: tokio::runtime::thread_pool::worker::run
  30: tokio::runtime::task::core::Core<T,S>::poll
  31: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  32: tokio::runtime::task::harness::Harness<T,S>::poll
  33: tokio::runtime::blocking::pool::Inner::run
  34: tokio::runtime::context::enter
  35: std::sys_common::backtrace::__rust_begin_short_backtrace
  36: core::ops::function::FnOnce::call_once{{vtable.shim}}
  37: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/liballoc/boxed.rs:1081:9
      <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/liballoc/boxed.rs:1081:9
      std::sys::unix::thread::Thread::new::thread_start
             at /rustc/04488afe34512aa4c33566eb16d8c912a3ae04f9/src/libstd/sys/unix/thread.rs:87:17
  38: start_thread
  39: __clone



Thread 'tokio-runtime-worker' panicked with message:
"Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks."

never had to open_wallet in previous version, im assuming it is opened when i provide the password to grin-wallet owner_api and everything worked fine there with same token: null. in fact i just now tried with v4.0.0 and it worked. also, setting refresh_from_node to false works

[bladedoyle]

Please restart the owner_api to get it back into a working state and test with a call to open_wallet:

shared_ecdh_key = call to "init_secure_api"
token = call to "open_wallet"
info = call to "retrieve_summary_info"

btw, there is a python owner_api example here: https://github.com/grinfans/grin.py/blob/main/wallet_v3_tests.py

[inb0x]

i tried using open_wallet and including the keychain_mask in the call to retrieve_summary_info with the same panic, no success
{"jsonrpc":"2.0","method":"retrieve_summary_info","params":{"token":"7c109d62e3251c2e7f8c68a213866bb00396b69f6de0b63bef7e9c69c2b4d648","refresh_from_node":true,"minimum_confirmations":1},"id":0}

[bladedoyle]

Ok, I see the same results as you.
Its not related to calling open_wallet.
This appears to be triggered by the wallet calling "refresh_from_node".
I hope we can get @jaspervdm to take a look.

[jaspervdm]

The problem does not occur to me when running the code in #573, could anyone double check?

[inb0x]

the code in #573 appears to fix it

[jaspervdm]

Thanks for verifying! We will be releasing v5.0.3 shortly, which includes this fix.