I know that the UI has a replay parked messages button, but I’d like to know if it’s possible to replay only some messages, if for whatever reason, some messages would cause problems to replay. I know I could truncate the stream to replay only messages after a certain point, but I’d like to be able to replay a single message or serveral messages in a row, or all messages of a type etc. Happy with a API based solution, just want to know if it’s possible.
As of now there is not a way of doing this, but I would be interested in hearing more on the use case as its not one I considered when originally implementing the parked/replay parked behaviours.
Adding the ability to do this in varying ways would not be a hard thing to do, just want to understand better the need to help in selecting between mechanisms.
Our use cases are that we have not replayed events immediately, and then some issues have been ‘resolved’ manually by help desk (things like document delivery which failed, have been done manually) and now replaying those events would result in duplicates being delivered. As a consequence of some events not being replayed immediately, and lack of capacity for analysing consequence of replaying the events from a long time ago, we would like to replay events parked by an issue introduced last week. Or knowing that some events not being replayed means some later process would now fail we would like to replay only events of that specific type.
Hope this helps, but happy to discuss further if needed.
The parked message stream is just a stream (I believe its surfaced via the http api but need to double check). You could feasibly do this on your own (just read through the stream).
Ok, but how do we ‘Replay’ the events? Or do you mean have the consumer read this stream and process the events? And if this is the case then how do we mark the events in the parked stream as processed?
Parked means they have already been marked as processed (and failed!). It is things that it had to move on from.
I suppose I don’t understand the process by which we would do this ourselves. I assumed there was some internal ‘stuff’ going on which redelivers the messages in the parked message stream to the original subscribers and removes them from the parked message stream at the same time. It’s not immediately obvious to me how we would replicate this behaviour on our own. I’m happy to do it but unsure exactly what would need to be done here…
I think you could also write a custom reprojection that ran against the parked stream and emitted events to another stream. Then you could have a competing consumer hooked up to handle events from that stream.
It depends on your use case, but if you automatically wanted to rehandle only some events and never intended to replay the entire parked stream, that might work.
Of course, if you replay and an item is entered into the stream again, I think that means it will be again emitted to your secondary stream. You will need to be okay with that and be able to handle or ignore that.
So parked means we went through all of the configured retrying etc and eventually parked it or were told by a consumer explicitly to park it and move on.
@Stephen Hmm custom park streams would not be a difficult addition… What precisely would be the use case associated with them?
Could “resolved manually by help desk” be something that is modeled explicitly in the domain, thus maybe avoiding the need to replay the events?
If “parked messages” would wind up populating a read model, maybe that could be used to determine if anything further (marking something as manually resolved by help desk?) needs doing?