Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
light-client: expose latest_trusted on Supervisor Handle #394
Changes from 2 commits
8eba90f
b3a5b1e
bca7fe8
a40dd11
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Interesting. I wasn't aware that these are needed for internal communication only. Looks like a good simplification. Especially removing the
pub
fromEvents
(nowHandleInput
) makes sense then 👍 I would definitely like to hear what @romac / @brapse think about this, too.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 itsSupervisor
, while others where only used as intermediates inside ofHandle
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. theSupervisor
run loop. By isolating the enum to the single purpose ofHandle -> 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.
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.
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 itslatest_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.