You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you work with the rpc feature of rabbot, you may be tempted to use the intermediate callback and more option.
If you do that (or plan to do that) be prepared to have a bunch of unacked messages in your queue.
There seems to be some weirdness that invalidates previously performed acks. It's a bit hard to explain, please have a look at the attached examples.
A workaround would be to use the noAck: true option upon consuming things. Of course, this may break your workflow so be vary.
The text was updated successfully, but these errors were encountered:
I've pinpointed the issue down to the ackBatch processing.
Since my usecase uses the batchAacking, I have an interval that fires each 500ms.
So imagine using msg.reply before and the next msg.reply after the batch processing, you end up in invalid states. The messages count is down to 0 and further acks will not be performed, resulting in unacked messages.
A better workaround (though, requires code change) is to remove the raw.ack()call and call msg.ack() in your business logic.
When you work with the rpc feature of rabbot, you may be tempted to use the intermediate callback and
more
option.If you do that (or plan to do that) be prepared to have a bunch of unacked messages in your queue.
There seems to be some weirdness that invalidates previously performed acks. It's a bit hard to explain, please have a look at the attached examples.
A workaround would be to use the
noAck: true
option upon consuming things. Of course, this may break your workflow so be vary.The text was updated successfully, but these errors were encountered: