Skip to content

replay: refactor set-root to enable alpenglow to take over #7452

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

AshwinSekar
Copy link

@AshwinSekar AshwinSekar commented Aug 11, 2025

Problem

In alpenglow, replay will no longer be the thread setting root. To prepare for this we refactor the set root to the votor crate.

Summary of Changes

This pulls in the votor crate from the Alpenglow repo but only for the root_utils file. The full upstreaming of this crate will take place after VoteStateV4 has landed in sdk master (bunch of dependencies to resolve that need this 😅 ).

The callgraph is

///
/// ReplayStage::check_and_handle_new_root -> root_utils::check_and_handle_new_root(callback)
///                                                             |
///                                                             v
/// ReplayStage::handle_new_root           -> root_utils::set_bank_forks_root(callback) -> callback()

This extra callback will take care of rooting the TowerBFT specific structures to maintain compatibility. In the future Alpenglow will call the root_utils function without the callback

@codecov-commenter
Copy link

codecov-commenter commented Aug 11, 2025

Codecov Report

❌ Patch coverage is 93.18182% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.2%. Comparing base (f6e6ff2) to head (189593b).
⚠️ Report is 4 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##           master    #7452     +/-   ##
=========================================
- Coverage    83.2%    83.2%   -0.1%     
=========================================
  Files         800      801      +1     
  Lines      362783   362869     +86     
=========================================
+ Hits       302195   302239     +44     
- Misses      60588    60630     +42     
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

.read()
.unwrap()
.highest_super_majority_root(),
);
Self::check_and_handle_new_root(

Choose a reason for hiding this comment

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

Out of paranoia, I inlined all of this and plugged into a diff checker. Code looks identical except for the following:

  1. We pass in parent_slot instead of vote_bank <-- seems like a good change
  2. We pass in highest_super_majority_root instead of block_commitment_cache <-- again, seems good
  3. Reverting to positional formatting of arguments for err <-- I think we should go back to string capture style
  4. Printing out pubkey when setting root <-- we pass pubkey through a couple API layers just for this.. is it worth it?

Copy link
Author

Choose a reason for hiding this comment

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

Reverted 3 189593b

As for 4, it makes debugging local-cluster tests easier. Perhaps a bit overboard but in alpenglow i've made every log print pubkey so that we can see what's going on.
If you prefer it removed I can keep a log w/ pubkey in event_handler when we call set root instead.

Choose a reason for hiding this comment

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

It feels weird tunneling down through a couple API layers just for local cluster test, but I agree it's soooo valuable to have for understanding those tests. I'm fine with it

Copy link
Author

Choose a reason for hiding this comment

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

agreed, would be nice if we could have some log magic to tag on pubkey in local cluster haha

@AshwinSekar AshwinSekar added the automerge automerge Merge this Pull Request automatically once CI passes label Aug 11, 2025
@steviez steviez removed the automerge automerge Merge this Pull Request automatically once CI passes label Aug 12, 2025
@steviez
Copy link

steviez commented Aug 12, 2025

I was out today and saw @bw-solana already approved - can you give me the chance to review tomorrow (Tue) before merging

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.

4 participants