-
Notifications
You must be signed in to change notification settings - Fork 785
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
[Merged by Bors] - Allow for a clock disparity on the duties endpoints #2283
Conversation
c47fa9c
to
c2f66a4
Compare
This is ready for review! It's running on all the SigP Pyrmont and Mainnet nodes and those pesky errors have stopped. |
.ok_or_else(|| warp_utils::reject::custom_server_error("unable to read slot clock".into()))? | ||
.epoch(T::EthSpec::slots_per_epoch()); | ||
|
||
if request_epoch == current_epoch |
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.
Don't think this makes a functional difference unless MAXIMUM_GOSSIP_CLOCK_DISPARITY
is greater than an epoch (lol) but this logic makes a bit more sense to me:
if current_epoch <= request_epoch && request_epoch <= tolerant_current_epoch + 1 {
} else if request_epoch > tolerant_current_epoch + 1 {
} else {
// request < current_epoch
}
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.
Agree it should be equivalent, but don't have a strong preference either way. The 4-way or has the advantage of being quite explicit.
Writing request_epoch >= current_epoch && request_epoch <= tolerant_current_epoch + 1
is also nice 😝
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.
Thanks @realbigsean, I agree that your statement is more universal but I do find what we've got to be easier to read. Perhaps that's just because I wrote it 🤔. I might leave it as-is 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.
Looks great, a smaller fix than I was expecting!
.ok_or_else(|| warp_utils::reject::custom_server_error("unable to read slot clock".into()))? | ||
.epoch(T::EthSpec::slots_per_epoch()); | ||
|
||
if request_epoch == current_epoch |
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.
Agree it should be equivalent, but don't have a strong preference either way. The 4-way or has the advantage of being quite explicit.
Writing request_epoch >= current_epoch && request_epoch <= tolerant_current_epoch + 1
is also nice 😝
bors r+ |
## Issue Addressed Resolves #2280 ## Proposed Changes Allows for API consumers to call the proposer/attester duties endpoints [`MAXIMUM_GOSSIP_CLOCK_DISPARITY`](https://github.com/sigp/lighthouse/blob/b34a79dc0b02e04441ba01fd0f304d1e203d877d/beacon_node/beacon_chain/src/beacon_chain.rs#L99-L102) earlier than the current epoch. For additional reasoning, see #2280 (comment). ## Additional Info NA
bors r- |
Canceled. |
bors r+ |
## Issue Addressed Resolves #2280 ## Proposed Changes Allows for API consumers to call the proposer/attester duties endpoints [`MAXIMUM_GOSSIP_CLOCK_DISPARITY`](https://github.com/sigp/lighthouse/blob/b34a79dc0b02e04441ba01fd0f304d1e203d877d/beacon_node/beacon_chain/src/beacon_chain.rs#L99-L102) earlier than the current epoch. For additional reasoning, see #2280 (comment). ## Additional Info NA
Pull request successfully merged into unstable. Build succeeded: |
Issue Addressed
Resolves #2280
Proposed Changes
Allows for API consumers to call the proposer/attester duties endpoints
MAXIMUM_GOSSIP_CLOCK_DISPARITY
earlier than the current epoch. For additional reasoning, see #2280 (comment).Additional Info
NA