Skip to content

Conversation

hinto-janai
Copy link
Contributor

@hinto-janai hinto-janai commented Jul 21, 2024

What

Implements the entirety of the cuprate-rpc-interface crate (with a few TODOs).

How

See below review.

@hinto-janai hinto-janai changed the title rpc: start cuprate-rpc-interface rpc: impl cuprate-rpc-interface Aug 1, 2024
Comment on lines +59 to +65
# 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.
Copy link
Contributor Author

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.

@hinto-janai hinto-janai marked this pull request as ready for review August 1, 2024 22:30
@hinto-janai hinto-janai requested a review from Boog900 August 1, 2024 22:30
/// - [`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
Copy link
Member

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.

@Boog900
Copy link
Member

Boog900 commented Aug 5, 2024

great work btw!

Comment on lines +26 to +31
// 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?
Copy link
Contributor Author

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.

Copy link
Member

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.

@hinto-janai hinto-janai requested a review from Boog900 August 5, 2024 20:52
@hinto-janai hinto-janai requested a review from Boog900 August 5, 2024 23:39
@Boog900 Boog900 merged commit 2776769 into Cuprate:main Aug 5, 2024
@hinto-janai hinto-janai deleted the rpc-interface branch August 6, 2024 01:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dependency Area: Related to dependencies, or changes to a Cargo.{toml,lock} file. A-docs Area: Related to documentation. A-rpc Area: Related to RPC. A-workspace Area: Changes to a root workspace file or general repo file.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants