rpc: avoid blocking executor in peer_getbasicinfo

[mooncitydev]

This change replaces blocking on the async runtime with a proper await when fetching network state for peer_getBasicInfo.

Using futures::executor::block_on inside jsonrpsee RPC handlers blocks the async runtime and can stall other RPC under load; this matches the async pattern already used in txwatch.rs.

made by mooncitydev

[n13]

Thanks - will look at this

[n13]

Overall: The change is correct in intent — replacing futures::executor::block_on with async/.await is the right thing to do. Blocking the async runtime inside an RPC handler can indeed stall the entire jsonrpsee executor under load. Thumbs up on the motivation.

One issue to flag:

The PR adds async-trait as a new crate dependency in node/Cargo.toml, but this is unnecessary. The codebase already uses jsonrpsee's re-export of async_trait — you can see it in txwatch.rs:

use jsonrpsee::{
	core::{async_trait, SubscriptionResult},
	proc_macros::rpc,

The PR should use jsonrpsee::core::async_trait instead of pulling in a separate async-trait dependency. This:

1. Avoids adding a redundant dependency to node/Cargo.toml
2. Actually matches the pattern in txwatch.rs (which the PR description claims to follow)
3. Guarantees the same async_trait version that jsonrpsee expects

The fix would be:

• Remove the async-trait.workspace = true line from node/Cargo.toml
• Change use async_trait::async_trait; to import from jsonrpsee instead:

use jsonrpsee::{core::RpcResult, core::async_trait, proc_macros::rpc, RpcModule};

(or group it however you prefer)

Everything else looks good — the async fn signature on the trait, the #[async_trait] on the impl block, and the .await on network.network_state() are all correct. The error handling is unchanged, which is fine.

[mooncitydev]

can we talk via tg?
thanks
t.me/moooncity