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

refactor: rename PohRecorder::is_same_fork_as_previous_leader #4939

Merged
merged 2 commits into from
Feb 13, 2025

Conversation

jstarry
Copy link

@jstarry jstarry commented Feb 12, 2025

Problem

is_same_fork_as_previous_leader is not a great name. The previous leader could produce 4 different forks with each of its leader blocks so saying "is same fork as previous leader" is kinda meaningless. This function is really checking if the start bank was produced by itself or the current leader.

Summary of Changes

Rename for clarity

Fixes #

@jstarry jstarry requested a review from bw-solana February 12, 2025 05:35
@@ -432,7 +432,7 @@ impl PohRecorder {
self.leader_bank_notifier.clone()
}

fn is_same_fork_as_previous_leader(&self, slot: Slot) -> bool {
fn start_slot_was_mine_or_previous_leader(&self, slot: Slot) -> bool {

Choose a reason for hiding this comment

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

I'm thinking this should just be "start slot was previous leader" even though it would technically return true if we happen to be starting from our own slot.

Rationale is:

  • If it's actually our block, we would want to skip grace ticks.
  • Immediately before this, we check the start bank collector ID to determine if it was ours, so practically speaking, it shouldn't return true due to matching on our slot.

Copy link
Author

Choose a reason for hiding this comment

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

I'm more in favor of explicitly documenting the true behavior to avoid misuse of this method in the future. It's true that the current usage effectively means "start slot was previous leader" but that depends on first calling fn start_slot_was_mine. If fn start_slot_was_mine isn't called first, it's possible that we return false for fn can_skip_grace_ticks when building off our own slot because fn start_slot_was_mine_or_previous_leader would be true and fn building_off_previous_leader_last_block would be false.

Choose a reason for hiding this comment

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

that makes sense. Although it depends on the slot being passed in (obviously expectation being it is the next leader slot this node will attempt to build). Maybe we should s/slot/my_next_leader_slot/ ?)

or maybe I'm just overthinking this one :)

what you have is definitely an improvement

Copy link
Author

Choose a reason for hiding this comment

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

Yeah I'll update that param name, it was bothering me too

Copy link
Author

Choose a reason for hiding this comment

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

Updated to next_leader_slot everywhere

@jstarry jstarry force-pushed the refactor/rename-poh-fn branch from 97655f6 to 89039e8 Compare February 12, 2025 12:59
bw-solana
bw-solana previously approved these changes Feb 12, 2025
@@ -432,7 +432,7 @@ impl PohRecorder {
self.leader_bank_notifier.clone()
}

fn is_same_fork_as_previous_leader(&self, slot: Slot) -> bool {
fn start_slot_was_mine_or_previous_leader(&self, slot: Slot) -> bool {

Choose a reason for hiding this comment

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

that makes sense. Although it depends on the slot being passed in (obviously expectation being it is the next leader slot this node will attempt to build). Maybe we should s/slot/my_next_leader_slot/ ?)

or maybe I'm just overthinking this one :)

what you have is definitely an improvement

Copy link

@bw-solana bw-solana left a comment

Choose a reason for hiding this comment

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

LGTM!

@jstarry jstarry merged commit e719aa4 into anza-xyz:master Feb 13, 2025
47 checks passed
@jstarry jstarry deleted the refactor/rename-poh-fn branch February 13, 2025 02:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants