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.
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.
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.
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.
I added some notes with a link to this comment thread.
substrate/client/service/src/lib.rs
Outdated
| 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.
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.
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.
niklasad1
left a comment
niklasad1
left a comment
There was a problem hiding this comment.
nice work, looks good to me
Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com>
Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com>
|
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. |
|
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. |
niklasad1
left a comment
niklasad1
left a comment
There was a problem hiding this comment.
Hey again,
Just to fix the waiting stuff then it should be good to go, sorry missed that
Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com>
|
Thank you!!! 🎉 |
github-project-automation
bot
moved this from Todo
to Done
in [preview] release tracker
6 participants
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 thanSocketAddris 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
Trequired)