Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

frame/utils: introduce substrate-rpc-client crate for RPC utils #12212

Merged
merged 15 commits into from
Oct 18, 2022

Conversation

niklasad1
Copy link
Member

@niklasad1 niklasad1 commented Sep 8, 2022

Close #8988

So in general I like this approach of using the sc-rpc-api instead of re-defining this stuff all over the place however it requires some super ugly type annotations because the trait itself in sc-rpc-api takes a bunch a trait type params.

So for example:

		ChainApi::<(), _, B::Header, ()>::finalized_head(self.as_online().rpc_client())
			.await
			.map_err(|e| {
				error!(target: LOG_TARGET, "Error = {:?}", e);
				"rpc finalized_head failed."
			})

In that cause we only care about Header but because the trait itself has 3 other type params that are unused in that call and we don't care about makes the code almost unreadable.

I tried this trick:

    trait WrapperChainApi<Number, Block, SignedBlock>: ChainApi<Number, Block::Hash, Block::Header, SignedBlock> 
    where
    // bounds here
    {}

but it doesn't work because the jsonrpsee traits are not object-safe.

polkadot companion: paritytech/polkadot#6162

@github-actions github-actions bot added the A3-in_progress Pull request is in progress. No review needed at this stage. label Sep 8, 2022
Cargo.toml Outdated Show resolved Hide resolved
use sp_runtime::traits::{Block as BlockT, Header as HeaderT};
use std::collections::VecDeque;

pub use jsonrpsee::{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there actually any logic change here as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have increased connection timeout and request timeout but nothing else.

In addition I removed this keep connection stuff completely instead if one wants make a request then a client needs instantiated otherwise it's not possible to get access the RPC trait stuff from the macros.

}

#[async_trait]
impl<Block: BlockT> HeaderSubscription<Block> for Subscription<Block::Header>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't you want this abstraction available do all jsonrpsee users?

although it would make sense to have it here in substrate as well. Better than nothing and better than being ONLY on try-runtime.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes most sense to have this one in substrate and not in jsonrpsee but maybe we could have a shared crate where because we need it subxt and perhaps somewhere else :P

We could probably implement it for T instead of Block::Header to work

Copy link
Contributor

@kianenigma kianenigma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, just reshuffling things around for better usability.

What I really want to explore someday, and if it doesn't have an issue you should make one for it, are a set of extension traits that bridge the gap between a frame storage item tyoe and jsonrpsee.

Imagine you import the EMP pallet, and from it you fetch the #[pallet::storage] type CurrentPhase = .... Imagine you had some extension trait that allowed you to do CurrentPhase::get_remote(...) and it would get this value for you from a remove node.

The nice thing here is that the storage item itself knows how to build its key, which is all we need from it, and then we directly pass that key to jsonrpsee under the hood to fetch.

Although, now that I have uttered this out, I think the future of Rust tooling for substrate is less and less importing pallets directly and using pallet types from subxt.

I had this idea almost 2 years ago. I think things have changed too much in the meantime :D

@kianenigma
Copy link
Contributor

In that cause we only care about Header but because the trait itself has 3 other type params that are unused in that call and we don't care about makes the code almost unreadable.

TBH I don't think the <_, .., _> is super bad. The _ in rust already helps a lot with this.

niklasad1 and others added 2 commits September 8, 2022 12:26
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
@niklasad1
Copy link
Member Author

TBH I don't think the <_, .., _> is super bad. The _ in rust already helps a lot with this.

The annoying thing is that jsonrpsee adds some trait bounds such as Send + Sync + DeserializeOwned + Serialize depending on the use-case so _ won't work that's why I used () in the code. I could add some comments about that.

@pmikolajczyk41
Copy link
Contributor

@niklasad1 I was about to start working on cleaning up remote-externalities create as a follow-up to our discussion to #12167 (step 2). However, if I'm not misguided, this PR will cover both steps (2. and 3.) of refactor at once, won't it? If so, let me know if I can help you with anything here :)

@niklasad1 niklasad1 changed the title [WIP]: introduce rpc-utils crate [WIP]: introduce substrate-rpc-client crate with shared RPC stuff Sep 9, 2022
@niklasad1
Copy link
Member Author

niklasad1 commented Sep 9, 2022

@niklasad1 I was about to start working on cleaning up remote-externalities create as a follow-up to our discussion to #12167 (step 2). However, if I'm not misguided, this PR will cover both steps (2. and 3.) of refactor at once, won't it? If so, let me know if I can help you with anything here :)

Yeah, it should cover both step 2 and 3.
Just take a look at the PR and let me know if anything is missing or if I broke something :)

Copy link
Contributor

@pmikolajczyk41 pmikolajczyk41 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generally, for me, it looks quite well, surely it is a step into right direction

regarding these long type specifiers, I'm afraid that some macro is the only easy way of removing such opaque calls; or we could provide some type shortcuts for common Block types

Comment on lines +464 to +467
impl<B: BlockT> Builder<B>
where
B::Hash: DeserializeOwned,
B::Header: DeserializeOwned,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might be helpful to create a DeserializableBlock trait with all such constraints

@niklasad1
Copy link
Member Author

niklasad1 commented Sep 9, 2022

regarding these long type specifiers, I'm afraid that some macro is the only easy way of removing such opaque calls; or we could provide some type shortcuts for common Block types

The reason why these type params are needed is because the rpc traits have generic params on the entire trait which could most likely be solved by moving the type params to each method instead of the entire trait but yeah a macro could work but then you would loose the help from the compiler...

@stale
Copy link

stale bot commented Oct 9, 2022

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the A5-stale Pull request did not receive any updates in a long time. No review needed at this stage. Close it. label Oct 9, 2022
@niklasad1 niklasad1 changed the title [WIP]: introduce substrate-rpc-client crate with shared RPC stuff frame/utils: introduce substrate-rpc-client crate for RPC utils Oct 10, 2022
@niklasad1 niklasad1 marked this pull request as ready for review October 10, 2022 09:03
@github-actions github-actions bot added A0-please_review Pull request needs code review. and removed A3-in_progress Pull request is in progress. No review needed at this stage. labels Oct 10, 2022
@niklasad1 niklasad1 added B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit and removed A5-stale Pull request did not receive any updates in a long time. No review needed at this stage. Close it. labels Oct 10, 2022
@niklasad1 niklasad1 mentioned this pull request Oct 10, 2022
1 task
@kianenigma
Copy link
Contributor

this can probably be used for #12439 cc @ruseinov

@ruseinov
Copy link
Contributor

yes

@ruseinov ruseinov self-requested a review October 13, 2022 08:22
Copy link
Contributor

@ruseinov ruseinov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approving this, looks broadly good. If we need some further modifications - we could make them within sub-du PR.

@niklasad1
Copy link
Member Author

bot merge

@paritytech-processbot paritytech-processbot bot merged commit 49734dd into master Oct 18, 2022
@paritytech-processbot paritytech-processbot bot deleted the na-jsonrpc-client-utils branch October 18, 2022 16:39
@kianenigma
Copy link
Contributor

@niklasad1 you are no longer using keep_connection here, is that expected?

@niklasad1
Copy link
Member Author

niklasad1 commented Oct 23, 2022

@niklasad1 you are no longer using keep_connection here, is that expected?

Yeah because one must create client to make a request and the client has just to kept just somewhere to maintain the connection.
See #12212 (comment) I don't see a point of having that option... but maybe you have a use-case somewhere where it's needed?!

@kianenigma
Copy link
Contributor

I am not into the details of the networking here, but either the logic related to this flag was removed by mistake, or the flag should have been removed too. Having the flag do nothing is wrong.

@niklasad1
Copy link
Member Author

Ok, the flag should be removed too then I thought I did that.

@Polkadot-Forum
Copy link

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-release-analysis/1026/2

ark0f pushed a commit to gear-tech/substrate that referenced this pull request Feb 27, 2023
…ritytech#12212)

* hack together a PoC

* Update utils/frame/rpc-utils/Cargo.toml

Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

* Update utils/frame/rpc-utils/src/lib.rs

Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>

* rpc_utils -> substrate_rpc_client

* try runtime: remove keep connection

* make CI happy

* cargo fmt

* fix ci

* update lock file

* fix

* fix

Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: kianenigma <kian@parity.io>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consolidate RPC client call utils
5 participants