-
Notifications
You must be signed in to change notification settings - Fork 808
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
feat(queue): Add hydrate queue admin command #2315
Conversation
6ed9e97
to
403f3bf
Compare
I presume that |
@robfletcher That's correct. We collect all of the messages with their descriptions and then just |
403f3bf
to
1be42eb
Compare
it("adds messages to the queue") { | ||
argumentCaptor<Message>().let { | ||
verify(queue, times(1)).push(it.capture()) | ||
assertType<CompleteStage>(it.firstValue) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you not just use argumentCaptor<CompleteStage>
in the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I can. Victimized by copy/paste.
a9d3df5
to
5cecbcb
Compare
5cecbcb
to
e32f4bc
Compare
Allows the ability to hydrate the work queue from the execution repository state. This is primarily intended for being able to recover a Redis failure while using the (upcoming) SQL backend, where losing the Redis will mean in-flight work is orphaned, but its state is still held in SQL and thus is recoverable.
A secondary use case can be made for "kicking" a stuck execution where a message was dropped and the execution is no longer progressing. Running the command against a single execution could potentially get things going again.
Example output from the API:
Example log output:
I probably need more tests, what other use cases should I be covering?