Releases: hirosystems/chainhook
v1.5.1
v1.5.0
1.5.0 (2024-04-06)
Features
- add brc-20 schemas for ordhook (#551) (1e25a8f)
- detect http / rpc errors as early as possible (e515116)
- rm blocks (f35498d)
- use stacks.rocksdb for predicate scan (#514) (0baae10), closes #513 #485
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
v1.4.0
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
- enable debug logs in release mode (#537) (fb49e28)
- improve error handling, and more! (#524) (86b5c78), closes #498 #521 #404 /github.com/hirosystems/chainhook/issues/517#issuecomment-1992135101 #517 #506 #510 #519
- log errors on block download failure; implement max retries (#503) (0fc38cb)
- metrics: update latest ingested block on reorg (#515) (8f728f7)
- order and filter blocks used to seed forking block pool (#534) (a11bc1c)
- seed forking handler with unconfirmed blocks to improve startup stability (#505) (485394e), closes #487
- skip db consolidation if no new dataset was downloaded (#513) (983a165)
- update scan status for non-triggering predicates (#511) (9073f42), closes #498
v1.3.1
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
},
...
]
}
}
}
]
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 theworking_dir
set in yourChainhook.toml
- Rerun Chainhook
This will rebuild your Stacks database from scratch.
v1.3.0
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 of0
if omitted- we now require
end_block
to be greater thanstart_block
- we now require the difference between
end_block
andstart_block
to be no more than1_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 astart_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
v1.2.1
v1.2.0
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
v1.1.1
v1.1.0
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 theirlast_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
- Predicates that were in
new
status when Chainhook was terminated will start scanning at the predicate'sstart_block
- Predicates that were in
streaming
status will return to ascanning
status, starting atlast_evaluated_block_height
to catch up on the missed blocks. Note, thenumber_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
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)