stop effectively requiring engine_exchangeTransitionConfigurationV1
#320
Conversation
ajsutton
left a comment
ajsutton
left a comment
There was a problem hiding this comment.
Strongly in favour of moving towards removing this call and the first step has to be for ELs to stop complaining if it's not called.
src/engine/specification.md
Outdated
| 4. Consensus Layer client software **MAY** poll this endpoint every 60 seconds. | ||
|
|
||
| 5. Execution Layer client software **SHOULD** surface an error to the user if it does not recieve a request on this endpoint at least once every 120 seconds. | ||
| 5. Execution Layer client software **SHOULD NOT** surface an error to the user if it does not recieve a request on this endpoint at least once every 120 seconds. |
There was a problem hiding this comment.
I would make this MUST NOT so that CLs can stop calling it and know the EL won't complain (given enough time for updates to happen etc).
|
I am slightly against changing the spec of the method. I would rather wait for #321 to take into effect as it tends to bring deprecation procedure into Engine API development process. IMO, we should not change the spec in order to deprecate methods. In this particular case we may do the procedure in the following steps:
|
Works for me. |
|
Closing in favour of deprecation notices in #420 |
3 participants
engine_exchangeTransitionConfigurationV1is not necessary anymore, so compatibly begin de-emphasizing it. This approach allows a staging whereby it becomes more optional for both CLs and ELs, but that both CLs and ELs should converge to neither sending nor requiringengine_exchangeTransitionConfigurationV1.A future PR, once this has progressed, can remove the requirement for ELs to process this message in any particular, way, but that currently creates compatibility challenges within the existing ecosystem.