BN: Fix el_manager timeouts issue in block processing. #6665
Conversation
Use predefined array of exponential timeouts when all the requests to EL has been failed.
| deadlineTime = | ||
| block: | ||
| let slotTime = (wallSlot + 1).start_beacon_time() - 1.seconds | ||
| if slotTime <= wallTime: | ||
| 0.seconds | ||
| else: | ||
| chronos.nanoseconds((slotTime - wallTime).nanoseconds) | ||
| deadlineObj = DeadlineObject.init(deadlineTime) |
There was a problem hiding this comment.
hmm. I think this proc is called also when syncing. If a block gets synced shortly before the end of a slot, this may give it a very short newPayload deadline (or even 0).
There was a problem hiding this comment.
There is present an overloaded procedure which still uses 8.seconds timeout and it will be used in all the places where DeadlineObject is not used as last argument.
There was a problem hiding this comment.
Overall, the exponential timeouts make more sense than the hardcoded ones from before. They are also short enough to work on both minimal and mainnet presets, and they should also improve latency to get back online.
https://github.com/ethereum/execution-apis/blob/main/src/engine/cancun.md
For reference, timeouts defined by spec are 8s on these, but have been removed in Prague for v4 newPayload. @tersec may know more about what that means or if it is intentional.
Use predefined array of exponential timeouts when all the requests to EL has been failed.
So now both operations
newPayloadandupdateHeadsharing single timeout of4.secondsonmainnetpreset.