-
Notifications
You must be signed in to change notification settings - Fork 53
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
chore(release): publish v1.4.2 #556
Merged
Merged
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
feat: detect http / rpc errors as early as possible
Chainhook's `chainhook_stx_highest_block_ingested` and `chainhook_btc_highest_block_ingested` metrics were not being updated on a reorg. This was causing the Chainhook node to appear to be lagging behing the source chains, event though Chainhook's reorg handler was functioning properly. This PR sets the highest block ingested metrics on a reorg based on the highest index block being applied in the reorg.
…stability (#505) ### Description If Chainhook restarts in the middle of a reorg taking place, it doesn't have any context for choosing the canonical fork. Then when block collisions take place, Chainhook fails to process the new blocks, causing gaps in the blocks Chainhook has available for evaluation. This PR seeds the stacks block indexer with unconfirmed blocks on startup, so that Chainhook has the necessary context to handle a reorg. Most of the PR is to add two tests: - I've added some new functionality to our very thorough indexer tests - In addition to providing the blocks to be mined and the order to mine them, we also now allow providing some "unconfirmed" blocks to seed the block pool with. - I've added some test cases that reproduce what caused outages on the Platform's Chainhook node - I've added a new service test that: - Verifies that unconfirmed blocks are stored on restart - Verifies that those blocks are used to seed the block pool, and that a reorg is handled correctly. I committed these tests _before_ adding the fix, so you can confirm the fix by checking out the commits with the new tests (96d8249 and 9aad55e), seeing that the tests break, then pulling the last commit to see that the fix works. Fixes #487
### Description Previously, we would only update the scanning status every 10 blocks _if_ the block we just scanned had a trigger. This leads to users not getting status updates on the predicates that don't trigger often. Now, we update status every 10 blocks that we scan. This could lead to some noisy logs, so it should possibly be shipped with #498
### Description The database consolidation loop doesn't need to happen if there is no new data. @lgalabru I'm interested in your thoughts on this. Potentially someone could break their stacks.rocksdb, then Chainhook wouldn't automatically fix it unless they deleted their archive to force a redownload, or a new archive becomes available. I think the tradeoff is worth it because of the improvements to startup time if users are repeatedly running `chainhook predicates scan`, or if the service goes down and needs to restart. --------- Co-authored-by: Chris Guimarães <cguimaraes.br@gmail.com>
### Description Previously, when using the `chainhook predicates scan` command, Chainhook would download a very large archive file to use as a data source for the scan **every time the command was run**. The Chainhook service (`chainhook service start`), however, implements rocksdb to allow storing this dataset locally. This PR uses the rocksdb that a user may have created locally to improve performance of the `chainhook predicates scan` command. If a rocksdb doesn't exist or can't be created, Chainhook will fallback to the original method of downloading the archive. Combined with #513, this PR reduces a simple scan of a few blocks from ~20 minutes to .02 seconds. Fixes #485
### Description Before this PR, Chainhook would loop infinitely if there is a problem downloading a BTC block, and it wouldn't log much information as to what was causing the failure. This PR implements better logging, and breaks out of the loop at 10 failed attempts.
### Description <!-- Describe the bug this PR fixes or the feature it adds. Link to any related issues and PRs --> #### Breaking change? <!-- If applicable, list the APIs/functionality which this PR breaks --> ### Example <!-- If applicable, add an example on how this improves the application --> --- ### Checklist - [ ] All tests pass - [ ] Tests added in this PR (if applicable)
### Description <!-- Describe the bug this PR fixes or the feature it adds. Link to any related issues and PRs --> #### Breaking change? <!-- If applicable, list the APIs/functionality which this PR breaks --> ### Example <!-- If applicable, add an example on how this improves the application --> --- ### Checklist - [ ] All tests pass - [ ] Tests added in this PR (if applicable) --------- Co-authored-by: Rafael Cardenas <rafael@rafaelcr.com>
chore: bump sdk + type versions + publish
fix: build error
Co-authored-by: Ludo Galabru <ludovic@galabru.com>
MicaiahReid
temporarily deployed
to
Development-mainnet
April 6, 2024 01:49
— with
GitHub Actions
Inactive
MicaiahReid
had a problem deploying
to
Development-testnet
April 6, 2024 01:49
— with
GitHub Actions
Error
MicaiahReid
had a problem deploying
to
Development-mainnet
April 6, 2024 01:50
— with
GitHub Actions
Error
MicaiahReid
had a problem deploying
to
Development-testnet
April 6, 2024 01:50
— with
GitHub Actions
Error
feat: rm unconfirmed blocks command
lgalabru
had a problem deploying
to
Development-mainnet
April 6, 2024 02:39
— with
GitHub Actions
Error
lgalabru
had a problem deploying
to
Development-testnet
April 6, 2024 02:39
— with
GitHub Actions
Error
lgalabru
had a problem deploying
to
Development-mainnet
April 6, 2024 02:40
— with
GitHub Actions
Error
lgalabru
had a problem deploying
to
Development-testnet
April 6, 2024 02:40
— with
GitHub Actions
Error
MicaiahReid
had a problem deploying
to
Development-mainnet
April 6, 2024 03:38
— with
GitHub Actions
Error
MicaiahReid
had a problem deploying
to
Development-testnet
April 6, 2024 03:38
— with
GitHub Actions
Error
MicaiahReid
had a problem deploying
to
Development-mainnet
April 6, 2024 03:38
— with
GitHub Actions
Error
MicaiahReid
had a problem deploying
to
Development-testnet
April 6, 2024 03:38
— with
GitHub Actions
Error
lgalabru
approved these changes
Apr 6, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's goo 🚀
🎉 This PR is included in version 1.5.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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.
No description provided.