-
Notifications
You must be signed in to change notification settings - Fork 49
rpc: impl cuprate-rpc-interface
#233
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
Conversation
cuprate-rpc-interface
cuprate-rpc-interface
# Unknown endpoint behavior | ||
TODO: decide what this crate should return (per different endpoint) | ||
when a request is received to an unknown endpoint, including HTTP stuff, e.g. status code. | ||
|
||
# Unknown JSON-RPC method behavior | ||
TODO: decide what this crate returns when a `/json_rpc` | ||
request is received with an unknown method, including HTTP stuff, e.g. status code. |
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.
TODO: I'm expecting small behavior decisions like this will be made as the handlers are created.
rpc/interface/src/rpc_handler.rs
Outdated
/// - [`RpcRequest`] as the generic `Request` type | ||
/// - [`RpcResponse`] as the associated `Response` type | ||
/// - [`RpcError`] as the associated `Error` type | ||
/// - `InfallibleOneshotReceiver<Result<RpcResponse, RpcError>>` as the associated `Future` type |
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 don't think we should put this bound InfallibleOneshotReceiver
on the implementer as it's quite restrictive and pretty much prevents the use of middleware.
great work btw! |
Co-authored-by: Boog900 <boog900@tutanota.com>
Co-authored-by: Boog900 <boog900@tutanota.com>
// TODO: <https://www.jsonrpc.org/specification#notification> | ||
// | ||
// JSON-RPC notifications (requests without `id`) | ||
// must not be responded too, although, the request's side-effects | ||
// must remain. How to do this considering this function will | ||
// always return and cause `axum` to respond? |
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.
This is (maybe) one of the differences that will be documented in the architecture book: https://www.jsonrpc.org/specification#notification.
On one hand, monerod
ignores this and following that behavior is easier, on the other hand, the specification very clearly states this is incorrect:
The Server MUST NOT reply to a Notification
My first thought is to test bitcoin/eth/zcash and see if they follow the spec, if so, I think we should as well.
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.
Yeah I think I agree, the spec does seem pretty firm there.
However it is probably not worth the effort if monerod is already breaking spec.
What
Implements the entirety of the
cuprate-rpc-interface
crate (with a few TODOs).How
See below review.