fix: validate predicate start_block and end_block
#489
+475
−236
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
MicaiahReid
had a problem deploying
to
Development-mainnet
GitHub Actions
Error
MicaiahReid
had a problem deploying
to
Development-testnet
GitHub Actions
Error
lgalabru
approved these changes
Feb 6, 2024
MicaiahReid
had a problem deploying
to
Development-mainnet
GitHub Actions
Error
MicaiahReid
had a problem deploying
to
Development-testnet
GitHub Actions
Error
MicaiahReid
had a problem deploying
to
Development-mainnet
GitHub Actions
Error
MicaiahReid
had a problem deploying
to
Development-testnet
GitHub Actions
Error
MicaiahReid
force-pushed
the
fix-scan-start-end-blocks
branch
from
2da51cf
to
b3d8a19
Compare
MicaiahReid
had a problem deploying
to
Development-mainnet
GitHub Actions
Failure
MicaiahReid
had a problem deploying
to
Development-testnet
GitHub Actions
Failure
MicaiahReid
added a commit
that referenced
this pull request
Feb 8, 2024
### Description Previously, the scanning threads had some validation for the `start_block` and `end_block` that was incorrect. This PR introduces validation that does the following: - We now allow `start_block` to be omitted by the user and we default to 0 - If there are no blocks in the database, we abort the scan and go to streaming mode rather than erroring (fixes #477) - If the user provides an `end_block`, we validate that it is greater than the `start_block` - If the `start_block` is greater than chain tip, we abort the scan and go to streaming mode rather than erroring (fixes #464) This PR also adds some validation to the `BlockHeights` class. Previously, it was possible to overload the `BlockHeights::BlockRange(start_block, end_block)` function to allocate a lot of memory into an empty array. We now have limits on this class. However, due to the above validation, it should not be possible to pass through parameters that reach theses limits (with the current usage of the class) until a chain height is up to `1_000_000`. --- ### Checklist - [x] All tests pass - [x] Tests added in this PR (if applicable)
github-actions bot
pushed a commit
that referenced
this pull request
Feb 8, 2024
## [1.3.0](v1.2.1...v1.3.0) (2024-02-08) ### Features * optionally serve Prometheus metrics ([#473](#473)) ([67a38ac](67a38ac)) ### Bug Fixes * adjust ordinal_number entry in ts client inscription transfer event, add new reveal data ([#476](#476)) ([28bf5c4](28bf5c4)) * remove early return for event evaluation ([#484](#484)) ([98f9e86](98f9e86)), closes [#469](#469) * remove unreachable panic; return instead ([#490](#490)) ([abe0fd5](abe0fd5)) * use cli feature for `cargo chainhook-install` ([#486](#486)) ([32f4d4e](32f4d4e)) * validate predicate `start_block` and `end_block` ([#489](#489)) ([e70025b](e70025b)), closes [#477](#477) [#464](#464)
vabanaerytk
added a commit
to vabanaerytk/chainhook
that referenced
this pull request
Aug 7, 2024
## [1.3.0](hirosystems/chainhook@v1.2.1...v1.3.0) (2024-02-08) ### Features * optionally serve Prometheus metrics ([#473](hirosystems/chainhook#473)) ([1a3e356](hirosystems/chainhook@1a3e356)) ### Bug Fixes * adjust ordinal_number entry in ts client inscription transfer event, add new reveal data ([#476](hirosystems/chainhook#476)) ([fe7ef78](hirosystems/chainhook@fe7ef78)) * remove early return for event evaluation ([#484](hirosystems/chainhook#484)) ([d0e2f60](hirosystems/chainhook@d0e2f60)), closes [#469](hirosystems/chainhook#469) * remove unreachable panic; return instead ([#490](hirosystems/chainhook#490)) ([c7894ac](hirosystems/chainhook@c7894ac)) * use cli feature for `cargo chainhook-install` ([#486](hirosystems/chainhook#486)) ([206cb17](hirosystems/chainhook@206cb17)) * validate predicate `start_block` and `end_block` ([#489](hirosystems/chainhook#489)) ([85f3e71](hirosystems/chainhook@85f3e71)), closes [#477](hirosystems/chainhook#477) [#464](hirosystems/chainhook#464)
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.
Description
Previously, the scanning threads had some validation for the
start_blockandend_blockthat was incorrect. This PR introduces validation that does the following:start_blockto be omitted by the user and we default to 0end_block, we validate that it is greater than thestart_blockstart_blockis greater than chain tip, we abort the scan and go to streaming mode rather than erroring (fixes Support futurestart_block#464)This PR also adds some validation to the
BlockHeightsclass. Previously, it was possible to overload theBlockHeights::BlockRange(start_block, end_block)function to allocate a lot of memory into an empty array. We now have limits on this class. However, due to the above validation, it should not be possible to pass through parameters that reach theses limits (with the current usage of the class) until a chain height is up to1_000_000.Checklist