Open swathipil opened 2 years ago
breadcrumbs from Richard about running into something similar in Go:
In go-amqp I have a function (called Prefetched()) that only exists to drain the internal message channel in the receiver.
Since you have full and wonderful control over your receiver you could do the same. Like a "Flush()"
One funny thing that happened to me is that I gave back a flushed message but it'd been so long since the last failure that they actually re-received it. So they got back a bum message (lock expired) and then they also, in the same batch, got the real message.
more things Richard said: "Richard mentioned that you want to be careful to flush messages but do it quickly or else you might end up re-receiving a message when the older one expires"
I should have known that was going to happen. I regret all the time I spent helping you.
Hi @swathipil, we deeply appreciate your input into this project. Regrettably, this issue has remained unresolved for over 2 years and inactive for 30 days, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.
Bug discovered while adding stress tests (#22852).
When a link is continuously force detached over a long period of time, we want to make sure that we continue receiving messages and the link attaches again/recovers. We also don't want to receive duplicate messages. However, we are receiving duplicate messages. I believe the message is not being dequeued from the internal message buffer/queue. To reproduce, run the following code: