-
Notifications
You must be signed in to change notification settings - Fork 65
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
keep predicate registration api open when startup predicates are passed #298
Labels
Comments
Agreed on starting the API regardless of the predicates. |
MicaiahReid
added a commit
that referenced
this issue
Sep 11, 2023
### Description Improves how we handle a restart of `chainhook service` while predicates are scanning/streaming. Here are the cases we now handle: 1. 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* 2. Predicates that were in `new` status when Chainhook was terminated will start scanning at the predicate's `start_block` 3. 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 4. If predicates were passed in at startup, we also register those to begin scanning, which previously didn't happen 5. 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: #298, fixes #390, fixes #402, fixes #403 --- ### Checklist - [x] All tests pass - [ ] Tests added in this PR (if applicable)
2 tasks
MicaiahReid
added a commit
that referenced
this issue
Sep 14, 2023
### Description This PR accomplishes a few things: - 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` Fixes #396, fixes #324 Also: Improves how we handle a restart of `chainhook service` while predicates are scanning/streaming. Here are the cases we now handle: 1. 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* 2. Predicates that were in `new` status when Chainhook was terminated will start scanning at the predicate's `start_block` 3. 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 4. If predicates were passed in at startup, we also register those to begin scanning, which previously didn't happen 5. 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: #298, fixes #390, fixes #402, fixes #403 #### Breaking change? The rename of `ScanningData`'s `number_of_blocks_sent` field could technically be considered breaking, let's discuss. ### Checklist - [x] All tests pass - [x] Tests added in this PR (if applicable) Test coverage before: 23.2% Test coverage after: 37.72%
🎉 This issue has been resolved in version 1.1.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
Currently, if
chainhook service start
is used with the--predicate-path
argument, we don't start the predicate registration API, even if it's enabled in the config:chainhook/components/chainhook-cli/src/cli/mod.rs
Line 440 in 69e1221
We should probably start the API regardless of if predicates are passed on startup.
The text was updated successfully, but these errors were encountered: