-
Notifications
You must be signed in to change notification settings - Fork 710
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plumb RPC listener up to caller #5038
Plumb RPC listener up to caller #5038
Conversation
User @nickvikeras, please sign the CLA here. |
None => vec![], | ||
}; | ||
|
||
let rpc_handlers = RpcHandlers { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't makes sense to add listen_addresses to RpcHandlers
this just an in-memory way to perform rpc calls, please remove it RpcHandlers.
Why did you add it (maybe I'm missing something)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you add it (maybe I'm missing something)?
Just because the RpcHandlers type is what is getting returned to the caller. Would a new return type that can provide both the Server
and the RpcHandlers
be preferred?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aight, I see one may want to know the listen addrs on the rpc endpoint after calling spawn_tasks
.
It's probably fine to keep the RpcHandlers
or rename to the RpcService or something, but it needs to documented that is represent a running RPC server as well with the legacy in-memory rpc calls
.
We may want to remove latter at some point, it was for WASM stuff before smoldot was a thing...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added some notes with a link to this comment thread.
substrate/client/service/src/lib.rs
Outdated
@@ -372,7 +382,7 @@ pub fn start_rpc_servers<R>( | |||
config: &Configuration, | |||
gen_rpc_module: R, | |||
rpc_id_provider: Option<Box<dyn RpcSubscriptionIdProvider>>, | |||
) -> Result<Box<dyn std::any::Any + Send + Sync>, error::Error> | |||
) -> Result<(Box<dyn std::any::Any + Send + Sync>, Option<SocketAddr>), error::Error> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with this.
But the return type is bit complicated and I don't remember why it's Box<dyn Any>
but would be much nicer with a wrapper type that has an API to get the listen_addr instead returning a tuple.... because the Server type already has this information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just used the Server type here, and moved the Drop wrapper up to the point where it was actually needed. Let me know if that suffices.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice work, looks good to me
Co-authored-by: Niklas Adolfsson <[email protected]>
Co-authored-by: Niklas Adolfsson <[email protected]>
Review required! Latest push from author must always be reviewed |
hey @nickvikeras This PR needs a prdoc description, instructions how write and generate such here the label should be node dev. Can you provide such a thing? I can help with that if you don't get it working. |
I added it in the latest commit. Let me know if it looks good. |
Gentle ping. Looks like this needs one more approval before it can be merged. |
Hey @nickvikeras Sorry, I merged #4792 and causes some merge conflicts that you have fix. |
@ niklasad1 sorry for the delay here. I just resolved the merge conflicts. I think this is good to merge again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey again,
Just to fix the waiting stuff then it should be good to go, sorry missed that
Co-authored-by: Niklas Adolfsson <[email protected]>
c72f9ab
Thank you!!! 🎉 |
Description
This PR allows the RPC server's socket address to be returned when initializing the server. This allows the library consumer to easily programmatically determine which port the RPC server is listening on. My use case for this is automated testing. I'd like to be able to simply specify that the server bind to port '0' and then test against whatever port the OS assigns dynamically. I will have many RPC servers running in parallel across many tests within a single process, and I don't want to have to deal with port conflicts.
Integration
Integration is straightforward. My main concern is that I am making non-backwards-compatible changes to public library functions. Let me know if I should leave backwards-compatible wrappers in place for any/all of the public functions that were modified.
Review Notes
The rationale for making the new listen_addresses field on the RpcHandlers struct a
[MultiAddr]
rather thanSocketAddr
is because I wanted it to be transport-agnostic as well as capable of supporting multiple listening addresses in case that is ever required by the RPC server in the future.Checklist
T
required)