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
As far as I understand a 'max_retries' is always set. What I want to achieve is that any messsages that land in the 'failed' transport will not have a 'max_retries'.
My use case is that during development, or finding problems on a production system, I need to debug messages. Messages can fail due to a problem in the code. After fixing the problem in the code, I want to retry a message and see if it works again. However, I can only retry 3 times (at least with the default setup). As a workaround I can set the 'max_retries' value a high number. But it would be nice if I just could disable 'max_retries', which having to write a custom retry strategy.
Currently my workflow of dealing failed messages is manually retrying them, mostly one-by-one to be sure. I am wondering if anyone else has a use case for disabling the 'max_retries' limit?
This seems to me a common use case. Why force someone to copy and paste the same classes in many projects to solve those common use cases and force to maintain different versions of the exactly same functionality?
Doing this seems to me like boilerplate and boilerplate should be avoided and made easier to manage.
And I already showed you config that does not use insanely large numbers but you still get your messages stored for 30+ years. My two "config only" examples would very well fit the scenario you describe.