Skip to content

feat: configurable max slot deep count #276

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

Merged
merged 1 commit into from
Mar 21, 2025

Conversation

AlexanderLukin
Copy link
Contributor

Add a new CL_API_MAX_SLOT_DEEP_COUNT env variable that specifies a maximum number of slots that the app uses to find a not missed consensus-layer slot.

Previously, this number was hard-coded in the appropriate constant in the ConsensusProviderService. As after the Pectra hardfork on Holeksy blocks became proposed significantly more rarely than usual, it became possible not to have any proposed blocks in the closest 32 slots, and so, the app gave up trying to find the closed proposed block and threw the error.

Now it is possible to configure this depth for cases like we see now on Holesky and extend this depth to any necessary value. So the app can look deeper into the slots chain and find the next (or previous) proposed block.

Also, some minor refactoring has been done in the
ConsensusProviderService and fixed incorrect numbers in the error message that is shown when the app cannot find the closest proposed block. Previously in case of such errors, the error message always looked like "Error when trying to get next not missed block header. From N to N" because of the recursive call.

Add a new `CL_API_MAX_SLOT_DEEP_COUNT` env variable that specifies a
maximum number of slots that the app uses to find a not missed
consensus-layer slot.

Previously, this number was hard-coded in the appropriate constant in
the `ConsensusProviderService`. As after the Pectra hardfork on Holeksy
blocks became proposed significantly more rarely than usual, it became
possible not to have any proposed blocks in the closest 32 slots, and
so, the app gave up trying to find the closed proposed block and threw
the error.

Now it is possible to configure this depth for cases like we see now on
Holesky and extend this depth to any necessary value. So the app can
look deeper into the slots chain and find the next (or previous)
proposed block.

Also, some minor refactoring has been done in the
`ConsensusProviderService` and fixed incorrect numbers in the error
message that is shown when the app cannot find the closest proposed
block. Previously in case of such errors, the error message always
looked like "Error when trying to get next not missed block header. From
N to N" because of the recursive call.
Copy link

@dputko dputko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just a few minor suggestions!

@AlexanderLukin
Copy link
Contributor Author

Thanks for the thoughtful review! These all are good suggestions, I agree with everything. I'll make these changes later in a separate PR.

@AlexanderLukin AlexanderLukin merged commit ee0e672 into develop Mar 21, 2025
5 checks passed
@AlexanderLukin AlexanderLukin deleted the feature/configurable-max-slot-deep-count branch March 21, 2025 11:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants