light-client: improve supervisor ergonomics #403
Conversation
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
added
enhancement
Codecov Report
@@ Coverage Diff @@
## master #403 +/- ##
======================================
Coverage 28.2% 28.2%
======================================
Files 130 129 -1
Lines 5383 5381 -2
Branches 1663 1666 +3
======================================
Hits 1519 1519
+ Misses 2795 2793 -2
Partials 1069 1069
Continue to review full report at Codecov.
|
| @@ -57,6 +60,9 @@ pub enum ErrorKind { | |||
|
|
|||
| #[error("invalid light block: {0}")] | |||
| InvalidLightBlock(#[source] VerificationError), | |||
|
|
|||
| #[error("internal channel disconnected")] | |||
| ChannelDisconnected, | |||
There was a problem hiding this comment.
Wouldn't it be nice to "decorate" the error with the underlying crossbeam error message?
There was a problem hiding this comment.
The reason we jump through these hoops is that the crossbeam errors don't derive Deserialize and Serialize which we need for our errors. Furthermore they only carry the message that failed to send, Would question how much value that has.
There was a problem hiding this comment.
Oh, I thought you can wrap errors in the error kinds which do not derive (de)serialize and still have serialization via anomaly but I might be wrong (or too tired). Doesn't sound like it's worth to further investigate here.
| loop { | ||
| let event = self.receiver.recv().unwrap(); | ||
| let event = self.receiver.recv().map_err(ErrorKind::from)?; |
CallbackabstractionHandleHandletrait methodsCloses #398
Implements ADR-007
Depends on #401
Wrote tests