-
Notifications
You must be signed in to change notification settings - Fork 2k
patch capabilities for old clients #14105
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
base: main
Are you sure you want to change the base?
Conversation
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.
Maybe parametrize the tests both against the edges right below and above the boundary as well as further away including even future versions.
i changed the tests to be more close to the check case, i dont think there's use in adding more cases |
Almog, clarification. This does not work if the new peer initiates the connection, as it will send the new capability that will be rejected by the old node. Is my understanding correct here? |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
# Conflicts: # chia/server/ws_connection.py
Conflicts have been resolved. A maintainer will review the pull request shortly. |
d45216c
to
7e5d629
Compare
@altendky suggested using https://packaging.pypa.io/en/stable/version.html for parsing the version, im up for that if we are ok with moving towards using that everywhere for versions, otherwise i feel this will only cause more confusion and prefer to leave as is. |
This PR has been flagged as stale due to no activity for over 60 days. It will not be automatically closed, but it has been given a stale-pr label and should be manually reviewed by the relevant parties. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This PR has been flagged as stale due to no activity for over 60 days. It will not be automatically closed, but it has been given a stale-pr label and should be manually reviewed by the relevant parties. |
make sure we dont send new capabilities for clients under 1.6.2
no breaking changes, fixes the issue where old clients would disconnect new one but only for the older clients outbound connections
example:
a 1.5 peer initiates a connection to a 1.6.2 peer, the 1.6.2 knows what 1.5 supports and only sends those to avoid the disconnect
this cant be done the other way because of who sends the first handshake message with the version and supported capabilties