-
-
Notifications
You must be signed in to change notification settings - Fork 244
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
Ability to receive a notification/check when a queue item has been completed/abandoned(or removed). #6
Comments
I am going to add a FileQueue where you can store the queue payload in file storage and then put a file marker item in the queue. This is a common pattern and we should make it easier. |
Sounds good 👍 |
Do we want to make any options available to say move any non processed items to a error folder? It might be nice to take a look at adbandoned items to figure out why they were discarded.. thoughts? In our case an event might not be able to be processed due to a serialization error. It would suck to discard them and never be able to reproduce. |
Yeah, we would pass in an IFileStorage impl and we would also need paths for where you want to store the files. We also allow archiving of completed items. So it would need to specify a queue folder, archive folder and deadletter folder. Probably have a deadletter TTL policy on it as well where it would cleanup deadletter files after a certain time. I think queues have a deadletter ttl already so the file storage should probably just honor that setting. |
yeah, I kind of agree. But how is it supposed to know what folder it's supposed to go into cause that's dynamically changing.. It's almost like this thing should be dumb. Maybe we call a method to calculate it and pass the queue item?? |
Yeah, I think the concrete queue would have to provide logic to figure out an archive folder. |
@ejsmith status on this issue? |
Add implementation for file storage in redis.
Currently we are abandoning queue items when there is an error which is great. But in some scenarios this doesn't work the greatest for example. When the queue item has been abandoned more times then the retry limit, there is no way to see when the queue item will be removed. As such we can't clean up data data payloads on disk that the queue item points to.
The text was updated successfully, but these errors were encountered: