Relayer retry API: add the # of messages prioritized in the queue to the http response #4059
Assignees
Labels
Comments
|
How is the retry being done? via CLI or? |
|
chatted with @kamiyaa, leaving some notes here for open-sourceness' sake:
The changes can be tested via the existing unit tests setup of the server but can also be tried manually against the relayer running in the |
|
It looks like there is an internal queue mechanism for processing these retry message (along with potential other messages?). With this current design, it's difficult to return the results of the message retry, because we will somehow need to wait for the operation to be processed and somehow get its results. I'm thinking we just remove the queue mechanism (for message retry) and just do the message retry logic in the http handler. |
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 6, 2025
#5043) ### Description Add a mpsc channel between relayer and message retry handler, so message retry handler knows the retry results from the relayer. `POST /message_retry` endpoint now returns a JSON with details on the retry request: ```rust #[derive(Clone, Debug, Deserialize, Serialize)] pub struct MessageRetryResponse { /// ID of the retry request pub uuid: String, /// how many pending operations were processed pub processed: usize, /// how many of the pending operations matched the retry request pattern pub matched: u64, } ``` ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues Fixes #4059 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing Updated unit tests to return a response so the handler is not blocked
tiendn
pushed a commit
to tiendn/hyperlane-monorepo
that referenced
this issue
Jan 11, 2025
hyperlane-xyz#5043) ### Description Add a mpsc channel between relayer and message retry handler, so message retry handler knows the retry results from the relayer. `POST /message_retry` endpoint now returns a JSON with details on the retry request: ```rust #[derive(Clone, Debug, Deserialize, Serialize)] pub struct MessageRetryResponse { /// ID of the retry request pub uuid: String, /// how many pending operations were processed pub processed: usize, /// how many of the pending operations matched the retry request pattern pub matched: u64, } ``` ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues Fixes hyperlane-xyz#4059 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing Updated unit tests to return a response so the handler is not blocked
tiendn
pushed a commit
to tiendn/hyperlane-monorepo
that referenced
this issue
Jan 11, 2025
hyperlane-xyz#5043) ### Description Add a mpsc channel between relayer and message retry handler, so message retry handler knows the retry results from the relayer. `POST /message_retry` endpoint now returns a JSON with details on the retry request: ```rust #[derive(Clone, Debug, Deserialize, Serialize)] pub struct MessageRetryResponse { /// ID of the retry request pub uuid: String, /// how many pending operations were processed pub processed: usize, /// how many of the pending operations matched the retry request pattern pub matched: u64, } ``` ### Drive-by changes <!-- Are there any minor or drive-by changes also included? --> ### Related issues Fixes hyperlane-xyz#4059 ### Backward compatibility <!-- Are these changes backward compatible? Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling? Yes/No --> ### Testing Updated unit tests to return a response so the handler is not blocked
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
Paul and I recently tried retrying messages for a particular domain shortly after starting up - because it takes some time to get to a point where the messages are actually in the prep queue, when we retried no messages were actually prioritized. We had to look at logs to realize it was bc of kinda slow startup.
Solution
Adding the # of messages in the queue that were prioritized would be useful to indicate this was the case
Nice to Have
Describe non-essential extensions to the solution
Additional features which should be implemented if they are easy to accommodate but otherwise can be skipped
The text was updated successfully, but these errors were encountered: