Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Relayer retry API: retry a subset of messages #4079

Closed
Tracked by #3321
tkporter opened this issue Jul 1, 2024 · 4 comments
Closed
Tracked by #3321

Relayer retry API: retry a subset of messages #4079

tkporter opened this issue Jul 1, 2024 · 4 comments
Labels
agent bounty small bounty size

Comments

@tkporter
Copy link
Collaborator

tkporter commented Jul 1, 2024

Problem

  • We have large prep queues
  • We probably want the ability to retry only messages that are important for the problem at hand -- e.g. maybe we want to retry everything for a given origin, or we want to retry only messages for a specific app

Solution

  • Probably involves using matching lists
  • It'd be nice to not need to construct these matching lists manually - maybe a CLI command or infra script to help us do this makes sense?
@tkporter tkporter added the agent label Jul 1, 2024
This was referenced Jul 1, 2024
Open
Closed
@daniel-savu daniel-savu added small bounty size bounty labels Oct 16, 2024
@Mantas-M
Copy link
Contributor

On it 🫡

@Mantas-M
Copy link
Contributor

Mantas-M commented Oct 17, 2024 •
edited
Loading

@tkporter Is there a preference to which automation to use for matching list generation?
I would assume it would be either:

  • Commander project
  • Bash script

From my understanding, both would essentially produce JSON, saved to a file, and to be used in the retry API endpoint as a payload, is that correct?

@daniel-savu
Copy link
Contributor

@tkporter Is there a preference to which automation to use for matching list generation? I would assume it would be either:

  • Commander project
  • Bash script

From my understanding, both would essentially produce JSON, saved to a file, and to be used in the retry API endpoint as a payload, is that correct?

@Mantas-M we actually just manually define the matching lists, so you don't need to worry about generation. The endpoint would just take in the JSON-encoded matching list string

@Mantas-M Mantas-M mentioned this issue Oct 23, 2024
Merged
github-merge-queue bot pushed a commit that referenced this issue Oct 30, 2024
@Mantas-M
feat: Refactor Relayer Retry Server (#4693)
fc82b30 
### Description

Refactor of the Relayer Retry Server to utilize matching lists.
This allows for a single POST request to be able to retry a wide range
of messages.

Since a matching list is used it is now possible to retry messages
depending on:
- Message Id
- Origin Domain
- Destination Domain
- Recipient Address
- Sender Address

## Example

Instead of the old request format
```
GET http://127.0.0.1:60843/message_retry?destination_domain=42
GET http://127.0.0.1:60843/message_retry?message_id=0x46910b1329ee53c86a023b322e9ca1c17e5f9f0bee789c77b0abced0a173d714
```
The new one should be used
```
POST http://127.0.0.1:60843/message_retry
```
With a JSON body like so:
```
[{"messageid": "*", "origindomain": "*", "senderaddress": "*", "destinationdomain": "*", "recipientaddress": "*"}]
```
Retry params can be both specific values and wildcards.

### Drive-by changes

- Moved `MockPendingOperation` to `hyperlane-test`
- Moved certain test utils for the relayer server to `hyperlane-test`
- Added functions to retrieve recipient and sender address from the
`PendingOperation`
- Added a `message_id` to the `MatchingList` struct to allow retries by
message id
- Removed `MessageRetryRequest` enum since it was no longer in use

### Related issues

Fixes #3571 #4079

### Backward compatibility

Yes

### Testing

Unit tests
@daniel-savu
Copy link
Contributor

closed in #4693

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
agent bounty small bounty size
Projects
Hyperlane Tasks
Status: Done
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tkporter @daniel-savu @Mantas-M