Engine API: deprecate exchangeTransitionConfiguration #375
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Feb 3, 2023
|
Decision from ACDC call 102: do not include into Shanghai and get back to this change in the next hard fork |
|
It's now the next hard fork. |
|
Closing in favour of the deprecation notice in #420 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Alternative to #339 which deprecates
engine_exchangeTransitionConfigurationV1.In discussion with @lightclient we came to decision that we should make the spec more explicit about deprecation path of this method.
The change proposed by this PR requires CL clients to not surface any error if a call of this method returns error, particularly, method not found. EL must either not surface an error if it doesn't receive calls to this method.
After these changes adhered by clients they will be able to remove support of this method entirely in uncoordinated fashion.
Note: these changes are similar to the ones proposed by #320, with a slight difference in CL client's behaviour which allows to break the dependency on both ends.