Use app context classifier in relayer submitter queues #3385
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
daniel-savu
commented
Mar 11, 2024
daniel-savu
changed the title
daniel-savu
commented
Mar 11, 2024
daniel-savu
commented
Mar 11, 2024
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3385 +/- ##
=======================================
Coverage 68.02% 68.02%
=======================================
Files 99 99
Lines 1032 1032
Branches 107 107
=======================================
Hits 702 702
Misses 284 284
Partials 46 46
|
daniel-savu
commented
Mar 11, 2024
tkporter
approved these changes
Mar 12, 2024
yorhodes
pushed a commit
that referenced
this pull request
Mar 22, 2024
### Description Includes the `app_context` classification in `PendingMessage`, and adds trait methods on `PendingOperation` to require always having such a label on `OpQueue` operations. This is done by reusing the matching list logic from the validator checkpoint labels (#3057). The nice thing is that this enables later support for retrying a group of `OpQueue` operations just by specifying the `app_context` label, without adding any new logic, since these labels are essentially matching list results. One downside to using `app_context` for retries is that the endpoint caller is constrained to only the matching lists defined by the relayer operator - however imo only the relayer operator that should be able to trigger retries. ### Drive-by changes The `OpQueue` type alias is converted to an actual struct, that stores the queue label (for metrics purposes), and also the `IntGaugeVec` metric: the generic group of metrics associated with that queue (basically only `submitter_queue_length` currently). ### Related issues - Fixes #3240 ### Backward compatibility Yes ### Testing Manual, by spinning up a relayer for injective and inevm. Sample metrics, from `--metricAppContexts '[{"name": "injectivelabel", "matchingList": [{"destination_domain": 6909546 }] }, {"name": "inevmlabel", "matchingList": [{"destination_domain": 2525 }] }]'` ``` hyperlane_submitter_queue_length{agent="relayer",app_context="inevmlabel",hyperlane_baselib_version="0.1.0",queue_name="confirm_queue",remote="inevm"} 11 hyperlane_submitter_queue_length{agent="relayer",app_context="inevmlabel",hyperlane_baselib_version="0.1.0",queue_name="prepare_queue",remote="inevm"} 0 hyperlane_submitter_queue_length{agent="relayer",app_context="injectivelabel",hyperlane_baselib_version="0.1.0",queue_name="confirm_queue",remote="injective"} 63 hyperlane_submitter_queue_length{agent="relayer",app_context="injectivelabel",hyperlane_baselib_version="0.1.0",queue_name="prepare_queue",remote="injective"} 13281 ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Includes the
app_contextclassification inPendingMessage, and adds trait methods onPendingOperationto require always having such a label onOpQueueoperations. This is done by reusing the matching list logic from the validator checkpoint labels (#3057).The nice thing is that this enables later support for retrying a group of
OpQueueoperations just by specifying theapp_contextlabel, without adding any new logic, since these labels are essentially matching list results. One downside to usingapp_contextfor retries is that the endpoint caller is constrained to only the matching lists defined by the relayer operator - however imo only the relayer operator that should be able to trigger retries.Drive-by changes
The
OpQueuetype alias is converted to an actual struct, that stores the queue label (for metrics purposes), and also theIntGaugeVecmetric: the generic group of metrics associated with that queue (basically onlysubmitter_queue_lengthcurrently).Related issues
Backward compatibility
Yes
Testing
Manual, by spinning up a relayer for injective and inevm. Sample metrics, from
--metricAppContexts '[{"name": "injectivelabel", "matchingList": [{"destination_domain": 6909546 }] }, {"name": "inevmlabel", "matchingList": [{"destination_domain": 2525 }] }]'