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 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)