-
Notifications
You must be signed in to change notification settings - Fork 224
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-client: expose latest_trusted on Supervisor Handle #394
Conversation
Self { sender } | ||
} | ||
|
||
/// Get latest trusted block from the [`Supervisor`]. | ||
pub fn latest_trusted(&mut self) -> Result<Option<LightBlock>, Error> { |
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.
In which case does this return Ok(None
)?
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.
When the underlying primary returns None
for its latest_trusted
. This is really a direct pass-through, and judging by the method on the Instance the latest trusted being none should be expected and is non-errornous behaviour.
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.
Makes sense. Need to check this out locally. I'm still wondering, when a primary doesn't yet have any trusted light block in store:
https://sourcegraph.com/github.com/informalsystems/tendermint-rs@b3a5b1e70cd2d7fb06361950d10951d51b3dce06/-/blob/light-client/src/supervisor.rs#L53-55
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.
If the primary always returns a trusted block, we should encode that in our types. While primary/witness might only be a operational concern as @milosevic pointed out during the call yesterday, there might a possibility to otherwise encode this expectation. For example with an enum distinguishing between node types/states. What would be the right way to find answers to these questions?
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 might be orthogonal to this PR but I think, we'd need to enumerate in which cases the primary does not yet have a trusted light block and then figure out if we want to treat these cases as errors for some use-cases instead (maybe further up, e.g. in the rpc).
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.
Follow-up in #395
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.
Left a comment in #395. Otherwise, I fully agree that we should try encode such invariants as possible in the types themselves.
/// The verification has succeded | ||
VerificationSuccess(Box<LightBlock>), | ||
/// The verification has failed | ||
VerificationFailure(Error), |
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.
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.
Yes they are internal only so a simplification here might makes sense.
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.
To give a bit more context, up until now this enum was a mix of events. Some of them used to send callbacked events from the Handle
up to its Supervisor
, while others where only used as intermediates inside of Handle
methods. This led to the use of wildcard match arms in places where only a subset of events where relevant, with undefined or panic behaviour. Additionally it would mask the case where a new variant was added but not accounted for in vital places, e.g. the Supervisor
run loop. By isolating the enum to the single purpose of Handle -> Supervisor
comms, all these downsides are removed and we get some help from the compiler when extending the surface between the two of them.
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.
Good catch! I wasn't so happy either with having both input and outputs/internal events in the same enum, but didn't see/look for the opportunity to simplify all this. 👍
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.
More thoughts on the matter in #185 (review)
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.
Great stuff @xla!
/// The verification has succeded | ||
VerificationSuccess(Box<LightBlock>), | ||
/// The verification has failed | ||
VerificationFailure(Error), |
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.
Good catch! I wasn't so happy either with having both input and outputs/internal events in the same enum, but didn't see/look for the opportunity to simplify all this. 👍
Self { sender } | ||
} | ||
|
||
/// Get latest trusted block from the [`Supervisor`]. | ||
pub fn latest_trusted(&mut self) -> Result<Option<LightBlock>, Error> { |
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.
Left a comment in #395. Otherwise, I fully agree that we should try encode such invariants as possible in the types themselves.
What would it take to get this out of draft into ready for review? I think the changes look good and make sense 👍 |
I still would like to extend the API to full-fill all needs of the |
I'd slightly prefer to merge this and get the remaining changes in a separate PR but either way is good to me. |
Handle::new(self.sender.clone()) | ||
} | ||
|
||
#[pre(self.peers.primary().is_some())] |
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 think we should remove this precondition (and other similar ones on verify_to_highest/target
) since we are actually raising a proper error if there is no primary, but this can be done in a follow-up (eg. by me).
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.
Tracking this in #400
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.
LGTM 👍
|
||
Light Client: | ||
|
||
- Expose latest_trusted from Supervisor Handle ([#394]) |
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.
Did we decide to have the light client changelog here or in the separate crate?
@brapse
Probably the changes related to the light client need a more general description and intro in the changelog but this is good for now 👌
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.
Just looked for precedence and there were entries for Light Client
further down.
Part of #219 and preparation for #363. Wanted to split out the new additions to the light-client
Supervisor
and itsHandle
to make it easier to review and move forward. The declared goal of this change-set is to introduce new API to full-fill the planned endpoints of #219.