Skip to content

Releases: hirosystems/chainhook

v1.5.1

12 Apr 20:31
Compare
Choose a tag to compare

1.5.1 (2024-04-12)

Bug Fixes

  • correctly track bitcoin block append metrics; add additional metrics (#563) (f85ac9e), closes #562

v1.5.0

06 Apr 03:46
Compare
Choose a tag to compare

1.5.0 (2024-04-06)

Features

Bug Fixes

  • build error (03b3938)
  • log errors on block download failure; implement max retries (#503) (3bfb0e1)
  • metrics: update latest ingested block on reorg (#515) (823713a)
  • order and filter blocks used to seed forking block pool (#534) (a2865b7)
  • revisit 7+ blocks reorg handling (#553) (184fd07)
  • seed forking handler with unconfirmed blocks to improve startup stability (#505) (b77aca2), closes #487
  • skip db consolidation if no new dataset was downloaded (#513) (b1469a6)
  • update scan status for non-triggering predicates (#511) (32cdfee), closes #498

v1.4.1

02 Apr 17:06
Compare
Choose a tag to compare

1.4.1 (2024-04-02)

Bug Fixes

  • limit scope of stacks_rw_db usage to free lock (#543) (0c287ca)
  • resolve dependencies (#548) (86334f4)
  • return unsupported kind for PoisonMicroblock (#545) (123ec9d)

v1.4.0

27 Mar 21:24
Compare
Choose a tag to compare

1.4.0 (2024-03-27)

Features

  • detect http / rpc errors as early as possible (ad78669)
  • use stacks.rocksdb for predicate scan (#514) (a4f1663), closes #513 #485

Bug Fixes

v1.3.1

14 Feb 23:35
Compare
Choose a tag to compare

1.3.1 (2024-02-14)

Thanks for using Chainhook! See our README for instructions on installing the latest version. Thank you to @janniks who contributed to this release, and to @aulneau who opened an issue that was fixed in this release.

If you're running a Chainhook node (i.e. chainhook service start ...), be sure to check out this note with some additional directions for enabling a fix.

Bug Fixes 🐛

fix: correctly determine PoX vs PoB block commitments (#499)

This fix changes some logic when parsing block data to correctly identify when a Stacks Block Commit is a PoX or PoB block commitment.

fix: add event index to transaction events (#495)

This PR adds the previously missing position field to a Stacks transaction event:

 "transactions": [
   {
     "metadata": {
       ...
       "receipt": {
         ...
         "events": [
           "position": { // new field
             "index": 0 
            },
            ...
         ]
       }
     }
  }
]
Note: Any users running a Chainhook node (i.e. `chainhook service start ...`) will not have transaction event positions stored in the database.

Because of this, all event position will have a value of:

"position": {
  "index": 0
}

To rebuild the database with this data filled in:

  • Upgrade to the latest version of Chainhook
  • Delete the stacks.rocksdb folder inside the working_dir set in your Chainhook.toml
  • Rerun Chainhook

This will rebuild your Stacks database from scratch.

v1.3.0

08 Feb 21:45
Compare
Choose a tag to compare

1.3.0 (2024-02-08)

Thanks for using Chainhook! See our README for instructions on installing the latest version. This release is mostly comprised of fixes that will add some stability when using Chainhook as a service or when scanning predicates. Thank you to @ryanwaits and @Xarek-Wizard who opened issues that were fixed in this release!

✨ New Features ✨

feat: optionally serve Prometheus metrics (#473)

This feature adds the option to serve Prometheus metrics for the Chainhook service. This may be helpful for those of you who are running a long-standing Chainhook service; a Prometheus scraper can be set up to gain insights into the health of your Chainhook node. This will be particularly helpful for us to have early detection of any service degradation in the Hiro Platform's hosted Chainhook service.

The feature can be used by specifying the --prometheus-port XXXX option in the CLI, or by adding the following to your config:

[monitoring]
prometheus_monitoring_port = 1111

Chainhook will behave as usual with this flag ommitted - metrics can still be retrieved via the observer's /ping endpoint, but they will not be formatted for ingestion by a Prometheus client.

Bug Fixes 🐛

fix: validate predicate start_block and end_block (#489)

Last week, we discovered a bug that could potentially cause Chainhook to use a massive amount of memory, which could crash a running node. This bug had to do with how we handle the start_block and end_block being set in a predicate, so we revamped the logic for this whole section of code:

  • start_block is now optional in a predicate and will have a default of 0 if omitted
  • we now require end_block to be greater than start_block
  • we now require the difference between end_block and start_block to be no more than 1_000_000. This is longer than both the Stacks and Bitcoin chains, so hopefully this isn't too limiting for our users 😅
  • BONUS FEATURE: we now allow a future start_block. If you set a predicate to have a start_block that is beyond the chain tip of the network, the predicate will be registered to Chainhook and will start being evaluated once the chain tip catches up

Some other fixes

  • adjust ordinal_number entry in ts client inscription transfer event, add new reveal data (#476) (28bf5c4)
  • remove early return for event evaluation (#484) (98f9e86), closes #469
  • remove unreachable panic; return instead (#490) (abe0fd5)
  • use cli feature for cargo chainhook-install (#486) (32f4d4e)

v1.2.1

30 Jan 18:01
Compare
Choose a tag to compare

1.2.1 (2024-01-30)

Bug Fixes

  • reduce memory usage in archive file ingestion (#480) (83af58b)

v1.2.0

25 Jan 22:15
Compare
Choose a tag to compare

1.2.0 (2024-01-25)

Features

  • add bad request support (7abe4f6)
  • add inscription transfer destination schema (526de7a)
  • add jubilee support for inscription_revealed schemas (#470) (823f430)
  • add Wallet Descriptor Support for Transaction Indexing (959da29)
  • broadcast ObserverEvent::BitcoinPredicateTriggered on successful requests (6407e2c)
  • broadcast ObserverEvent::BitcoinPredicateTriggered on successful requests (a6164ea)
  • introduce signet mode (549c775)

Bug Fixes

  • buffer decoding of archive file to reduce memory usage (#450) (f1b89f7), closes #401
  • skip empty chunks when decoding gz (b4ce82f)
  • stacks-indexer: prevent subtract with overflow (#449) (d8d9979)
  • update ordhook URLs on typescript client (9462ae3)

v1.1.1

11 Oct 22:08
Compare
Choose a tag to compare

1.1.1 (2023-10-11)

Bug Fixes

v1.1.0

10 Oct 21:33
Compare
Choose a tag to compare

v1.1.0 (2023-10-10)

Thanks for using Chainhook! See our README for instructions on installing the latest version. If you're running your own node, be sure to check out this note on updating to the latest version. Also, thank you to our first-time contributor @qustavo, who fixed how op_return predicates are evaluated!

✨ New Features ✨

feat: allow matching with regex for stacks print_event (#380)

This PR introduces the ability to match on a print_event's values with a regex string rather than just with the previous contains field.

This allows the following new if_this condition for a stacks predicate:

{
  "scope": "print_event",
  "contract_identifier": "ST3AXH4EBHD63FCFPTZ8GR29TNTVWDYPGY0KDY5E5.loan-data",
  "regex": "... some regex to match on the event data"
}

Fixes #348

feat: augment predicate status returned by GET/LIST endpoints (#397)

This PR:

  • renames/adds/removes predicate statuses according to the flowchart in docs/images/predicate-status-flowchart/PredicateStatusFlowchart.png
  • adds more context to errors returned in Interrupted status
  • adds status data to GET /v1/chainhooks endpoint
  • fixes bug in chainhook service where block streaming continued past end_block
  • Improves how we handle a restart of chainhook service while predicates are scanning/streaming.
    • Predicates that were in scanning status when Chainhook was terminated will resume scanning starting from their last_evaluated_block_height. Note: because we only save predicate status every 10 scans, we could end up re-emiting matches on a resetart
  • Predicates that were in new status when Chainhook was terminated will start scanning at the predicate's start_block
  • Predicates that were in streaming status will return to a scanning status, starting at last_evaluated_block_height to catch up on the missed blocks. Note, the number_of_blocks_to_scan is set to 0 for this temporary catch-up, as it's difficult to compute the number of remaining blocks in the context of this change
  • If predicates were passed in at startup, we also register those to begin scanning, which previously didn't happen
  • We now allow passing in a predicate at startup and registering additional predicates with the predicate registration server. This means that if you use the same startup predicate repeatedly, it will already be saved in redis and not be reloaded.
    Fixes #396, #324, #298, #390, #402, and #403
NOTE: This version of Chainhook updates some of the database that is stored in redis if you're running a Chainhook node. When you restart, your existing predicates may not be loaded. If you have this problem and need those predicates to be loaded, we have written a migration script that can be run. [Create an issue](https://github.com/hirosystems/chainhook/issues/new/choose) to reach out and we can assist.

Bug Fixes 🐛

  • introduce "data_handler_tx" (ee486f3)
  • chainhook not being registered (5a809c6)
  • ensure that the parent block was previously received. else, fetch it (2755266)
  • migrate to finer zmq lib (4eb5a07)
  • prevent panic when scanning from genesis block (#408) (1868a06)
  • remove event_handlers (6fecfd2)
  • retrieve blocks until tip (5213f5f)
  • revisit approach (67a34dc)
  • use crossbeam channels (ea33553)
  • workflow (d434c93)