Summary
futures::executor::block_on in RpcClient is a foot-gun. The client uses it for connection setup inside what may already be a tokio runtime context. This will panic if called inside an active tokio runtime — you cannot nest block_on in tokio.
Details
The service side uses #[tokio::main] correctly, but the client is a landmine for anyone embedding it in an existing async app.
Calling RpcClient methods from within a tokio context (e.g. inside a #[tokio::main] or from a spawned task) triggers:
thread 'main' panicked at 'cannot execute `LocalPool::run_until` after `it has been dropped`'
or similar nested-runtime panics.
Proposed Fix
Make RpcClient natively async — replace futures::executor::block_on with proper async fn signatures, letting the caller drive the executor. Optionally provide a blocking convenience wrapper that spawns its own runtime only if none is detected.
Impact
Any user embedding girolle's RPC client inside an existing async application (actix-web, axum, tonic, etc.) will hit this.
Labels
bug, help wanted
Summary
futures::executor::block_oninRpcClientis a foot-gun. The client uses it for connection setup inside what may already be a tokio runtime context. This will panic if called inside an active tokio runtime — you cannot nestblock_onin tokio.Details
The service side uses
#[tokio::main]correctly, but the client is a landmine for anyone embedding it in an existing async app.Calling
RpcClientmethods from within a tokio context (e.g. inside a#[tokio::main]or from a spawned task) triggers:or similar nested-runtime panics.
Proposed Fix
Make
RpcClientnatively async — replacefutures::executor::block_onwith properasync fnsignatures, letting the caller drive the executor. Optionally provide a blocking convenience wrapper that spawns its own runtime only if none is detected.Impact
Any user embedding girolle's RPC client inside an existing async application (actix-web, axum, tonic, etc.) will hit this.
Labels
bug, help wanted