Processing of "reclaimed" messages?

[le-yak]

Notice: I am currently just discovering the Redis protocol (investigating for a PoC), please forgive my poor understanding of the protocol

When calling streamer:listen --reclaim, I was expecting the registrered MessageReceiver(s) be triggered over the reclaimed pending messages.

The command calls ListenCommand::reclaimMessages(), but as far as I understand, this method just claims the ownership of the pending messages without acting upon them. It seems there is no further action on such messages, or am I missing another workflow elsewhere?

My assumption here is that reclaimed messages are those pulled by another consumer but unacknowledged for at least --reclaim milliseconds, and should be considered lost in transit.

If there is indeed an issue here, I'd be happy to propose a fix (e.g. invoke the MessageReceiver(s) here, or move it to the "Failed Messages" list?).

[prwnr]

@le-yak this option calls the Streams https://redis.io/commands/xclaim method and it was created to mimic it. so therefore there are no side effects. (Im not using this option on a daily basis tbh) -but this is more or less meant to have a side process to reclaim messages that were not processed by main consumers for some reason (error, server down), because those messages could get stuck on those consumers.

however Im sort of open for a suggestion to add more functionality to this option (but do note that there is a separate failed:retry command added recently, that deals with unexpected errors and their re-attempt)

sorry for late response, but github ends up in spam on my mail

[le-yak]

Hello, my apologies for not returning earlier, we decided to move away from redis for our use case. In the meantime, my memory has become a bit blurry, so the below may be a bit inaccurate.

If a MessageReceiver crashes with a fatal error (e.g. out of memory), the exception handler cannot kick-in and therefore does not have the chance to "re-queue" the failed message. If I recall correctly (and this is a big "if"), the message is lost from sight by the streamer:failed:* commands.

I do not clearly remember trying calling stream:failed:retry after --reclaim and this may very well address the scenario. If it is not already the case, I suggest --reclaim should "re-queue" the message for later processing (processing the messages immediately, as I was expecting in my first message, may go against the Redis semantics).

Thanks for this library, I will use it in our future projects in case we return to Redis.

[prwnr]

sounds like a valid concern. I will try to look into it when I will have some time. thanks for your input