-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add ContactInfo handling for shred versioning #34286
Add ContactInfo handling for shred versioning #34286
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #34286 +/- ##
=======================================
Coverage 81.9% 81.9%
=======================================
Files 819 819
Lines 219741 219747 +6
=======================================
+ Hits 180062 180089 +27
+ Misses 39679 39658 -21 |
gossip/src/crds.rs
Outdated
CrdsData::ContactInfo(node) => { | ||
// Can't insert into self.nodes since not all validators support ContactInfo yet | ||
// Querying self.nodes (get_nodes_contact_infos()) assumes we're pulling LegactContactInfo | ||
self.shred_versions.insert(pubkey, node.shred_version()); |
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.
hmmm, wondering if we should hold off updating self.shred_versions
for now until we have switched to use the new contact-info.
e.g. you may get legacy and new contact-infos from the same node with different shred-versions.
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.
ahhh i see ya that makes sense. crds.get_shred_version()
is not aware of the differences between ContactInfo
and LegacyContactInfo
so i could see how this would get mixed up. and ya the insert would just overwrite the other shred version for the same pubkey. will remove
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, thanks.
I think we want this to be backported to v1.17 as well.
Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis. |
* handle ContactInfo in places where only LegacyContactInfo was used * missed a spot * missed a spot * import contact info for crds lookup * cargo fmt * rm contactinfo from crds_entry. not supported yet * typo * remove crds.nodes insert for ContactInfo. not supported yet * forgot to remove clusterinfo in remove() * move around contactinfo match arm * remove contactinfo updating crds.shred_version (cherry picked from commit 8ed149a)
) (#34570) Add ContactInfo handling for shred versioning (#34286) * handle ContactInfo in places where only LegacyContactInfo was used * missed a spot * missed a spot * import contact info for crds lookup * cargo fmt * rm contactinfo from crds_entry. not supported yet * typo * remove crds.nodes insert for ContactInfo. not supported yet * forgot to remove clusterinfo in remove() * move around contactinfo match arm * remove contactinfo updating crds.shred_version (cherry picked from commit 8ed149a) Co-authored-by: Greg Cusack <greg.cusack@solana.com>
Problem
No support for new ClusterInfo for shred versioning/matching
Summary of Changes
add in ContactInfo support
Fixes #