Skip to content
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 23 commits into from
Apr 6, 2024
Merged

chore(release): publish v1.4.2 #556

merged 23 commits into from
Apr 6, 2024

Conversation

MicaiahReid
Copy link
Collaborator

No description provided.

lgalabru and others added 19 commits March 1, 2024 16:14
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
Co-authored-by: Ludo Galabru <ludovic@galabru.com>
Copy link
Member

@lgalabru lgalabru left a comment

Choose a reason for hiding this comment

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

Let's goo 🚀

@MicaiahReid MicaiahReid merged commit 056080b into main Apr 6, 2024
7 of 11 checks passed
Copy link

github-actions bot commented Apr 6, 2024

🎉 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
Labels
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

None yet

2 participants