Skip to content
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

light-node: RPC server #363

Merged
merged 33 commits into from
Jul 7, 2020
Merged

light-node: RPC server #363

merged 33 commits into from
Jul 7, 2020

Conversation

xla
Copy link
Contributor

@xla xla commented Jun 23, 2020

Adds an RPC server to expose internal state of a light node. Besides adding the general infrastructure it provides the first endpoint under /state as described in #219.

First part of #219
Depends on #394
Depends on #403

@xla xla added light-client Issues/features which involve the light client rpc labels Jun 23, 2020
@xla xla requested a review from liamsi June 23, 2020 13:38
@xla xla self-assigned this Jun 23, 2020
@xla
Copy link
Contributor Author

xla commented Jun 29, 2020

Supervisor changes have been split out into #394.

xla added 2 commits June 30, 2020 21:58
As we start to depend on the surface of the `Handle` we benefit from it
being a trait that can be implemented on a per need basis. This will
result in less overhead constructing object graphs in places where we
wannt to assert behaviour of other types in remote places, i.e. the
light-node rpc server. Overall we hope for an increased ease in writing
tests on module level.

Ref #219
@xla
Copy link
Contributor Author

xla commented Jun 30, 2020

Depends on #401

}
}

const LIGHTBLOCK_JSON: &str = r#"
Copy link
Member

@liamsi liamsi Jul 6, 2020

Choose a reason for hiding this comment

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

Is that needed twice? Here and above (in light-node/examples/rpc.rs)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The example is temporary to help with the integration work, wouldn't it to leave as is mid-term.

@xla xla marked this pull request as ready for review July 6, 2020 17:12
@xla xla requested review from romac, brapse and ebuchman July 6, 2020 17:14
}
}
#[error("i/o error: {0}")]
Io(String),
Copy link
Member

Choose a reason for hiding this comment

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

Just out of curiosity: why did you decide to wrap the underlying error as a string here (as opposed to using the #[from] directive)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because io::Error doesn't implement Clone. Which we mind not need anymore on our Kind as I refrained from returning our custom errors in the rpc server, as I wasn't able to get mapping to the jsonrpc error to work.

Copy link
Member

Choose a reason for hiding this comment

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

One way to work around the lack of Clone on io::Error is to use the anomaly::Context wrapper (as shown in the docs), which would look something like that:

diff --git a/light-node/src/error.rs b/light-node/src/error.rs
index 094799b..7162c03 100644
--- a/light-node/src/error.rs
+++ b/light-node/src/error.rs
@@ -1,8 +1,9 @@
 //! Error types
 
-use std::io;
 use std::net;
 
+use anomaly::{BoxError, Context};
+
 /// Error type
 pub type Error = anomaly::Error<Kind>;
 
@@ -18,12 +19,15 @@ pub enum Kind {
     Config,
 
     /// Input/output error
-    #[error("i/o error: {0}")]
-    Io(String),
+    #[error("i/o error")]
+    Io,
 }
 
-impl From<io::Error> for Kind {
-    fn from(err: io::Error) -> Self {
-        Self::Io(format!("{}", err))
+impl Kind {
+    /// Add additional context (i.e. include a source error and capture a backtrace).
+    /// You can convert the resulting `Context` into an `Error` by calling `.into()`.
+    pub fn context(self, source: impl Into<BoxError>) -> Context<Self> {
+        Context::new(self, Some(source.into()))
     }
 }
+
diff --git a/light-node/src/rpc.rs b/light-node/src/rpc.rs
index 544dcb4..f6b190f 100644
--- a/light-node/src/rpc.rs
+++ b/light-node/src/rpc.rs
@@ -25,7 +25,7 @@ where
             AccessControlAllowOrigin::Any,
         ]))
         .start_http(&addr.parse().map_err(error::Kind::from)?)
-        .map_err(error::Kind::from)?;
+        .map_err(|e| error::Kind::Io.context(e))?;
 
     srv.wait();

Copy link
Member

Choose a reason for hiding this comment

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

PR at #413

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah was looking at the Context as we also use it in the light-client crate. You do loose the From semantics with it, correct? As in you have to know which variant to construct when mapping.

Copy link
Member

Choose a reason for hiding this comment

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

You do loose the From semantics with it, correct? As in you have to know which variant to construct when mapping.

I would say that you just have to be more explicit, rather than let the compiler pick the appropriate From instance based on the (static) type of the underlying error, which in this case is a io::Error. So you don't really lose anything aside from the From instance, which in this case is not appropriate for io::Error because of the lack of Clone bound. If io::Error was Clone, then you would use #[from] like you did for net::AddrParseError.

@@ -0,0 +1,146 @@
//! Basic example of running the RPC server. This is a temporary show-case and should be removed
//! once integrated in the light node proper. To test the `/state` endpoint run:
Copy link
Member

Choose a reason for hiding this comment

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

👍

ErrorKind::Io.context(err).into()
impl Into<jsonrpc_core::types::Error> for Kind {
fn into(self) -> jsonrpc_core::types::Error {
todo!()
Copy link
Member

Choose a reason for hiding this comment

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

Did you leave this a todo!() on purpose?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See https://github.com/informalsystems/tendermint-rs/pull/363/files#r450373699 - I think the whole conversion can go. We don't use it at the moment.

light-node/src/rpc.rs Outdated Show resolved Hide resolved
Co-authored-by: Ismail Khoffi <Ismail.Khoffi@gmail.com>
@codecov-commenter
Copy link

Codecov Report

Merging #363 into master will increase coverage by 0.2%.
The diff coverage is 24.3%.

Impacted file tree graph

@@           Coverage Diff            @@
##           master    #363     +/-   ##
========================================
+ Coverage    30.4%   30.7%   +0.2%     
========================================
  Files         130     131      +1     
  Lines        5448    5464     +16     
  Branches     1686    1695      +9     
========================================
+ Hits         1659    1678     +19     
+ Misses       2640    2603     -37     
- Partials     1149    1183     +34     
Impacted Files Coverage Δ
light-client/src/components/scheduler.rs 47.6% <ø> (ø)
light-node/src/error.rs 0.0% <0.0%> (ø)
light-node/src/rpc.rs 36.0% <36.0%> (ø)
light-client/src/types.rs 47.8% <0.0%> (-7.2%) ⬇️
light-client/src/supervisor.rs 31.0% <0.0%> (-0.9%) ⬇️
tendermint/src/time.rs 47.2% <0.0%> (ø)
tendermint/src/block/commit.rs 54.5% <0.0%> (ø)
tendermint/src/validator.rs 50.0% <0.0%> (+0.9%) ⬆️
tendermint/src/signature.rs 37.5% <0.0%> (+4.1%) ⬆️
... and 5 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9b78fc5...3cce7af. Read the comment docs.

@@ -7,11 +7,18 @@ publish = false

[dependencies]
abscissa_tokio = "0.5"
anomaly = { version = "0.2", features = [ "serializer" ] }
Copy link
Member

Choose a reason for hiding this comment

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

@tarcieri @tony-iqlusion Mind chiming in here? It's been a while since I actively used all 3 dependencies: anomaly, thiserror, and abscissa. Does it make sense to mix those here? Doesn't make abscissa using anomaly in the same crate obsolete? I'm a bit lost here.

Copy link
Contributor

@tarcieri tarcieri Jul 6, 2020

Choose a reason for hiding this comment

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

Error handling in Abscissa is in the middle of an overhaul to switch to eyre (or if the improvements in eyre end up being upstreamable, potentially anyhow) /cc @yaahc

I plan on eventually phasing out anomaly at this point (too many crates to manage, and there are better options now)

Copy link
Member

Choose a reason for hiding this comment

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

Good to know thanks!

Copy link

Choose a reason for hiding this comment

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

It looks like there's a decent chance that the changes will get upstreamed back into anyhow, not sure how long it will be though.

liamsi
liamsi previously approved these changes Jul 6, 2020
Copy link
Member

@liamsi liamsi left a comment

Choose a reason for hiding this comment

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

I think It's OK to merge this as is to move forward with the cli / light node tmrw.

Copy link
Contributor

@brapse brapse left a comment

Choose a reason for hiding this comment

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

👍

@brapse brapse merged commit 1b46e32 into master Jul 7, 2020
@brapse brapse deleted the xla/219-light-node-rpc branch July 7, 2020 08:00
@romac
Copy link
Member

romac commented Jul 7, 2020

Great work @xla! 🥇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
light-client Issues/features which involve the light client rpc
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants