I’m using a rate limiting approach similar to the one in https://docs.particular.net/samples/throttling/ and the MSMQ transport. What I have found, though, is that if a message fails and generates an immediate retry, once the
DelayMessage method is called, we lose the immediate retry count, so it gets set back to zero.
In one specific case I observed, due to another bug in the application that caused the message handler to always generate exceptions, I ended up with an infinite cycle of immediate retries due to the delay clearing the retry count. This meant that the message never got redirected to the error queue. I ended up having to manually remove the timeout related to the rate limiting from my database to stop the cycle of retries.
For delayed retries, I was able to copy the delayed retry headers in my
DelayMessage method so that they work correctly. As a result, for the time being, I have disabled immediate retries and increased my number of delayed retries to compensate.
Is there any way to detect whether the message being processed is an immediate retry or to retain the immediate retry state when delaying processing? Alternatively, is there a better way to handle this situation?