Closed DickyMacias closed 7 months ago
Hi @DickyMacias! Thanks for writing this up.
the 'retry all' function might not be considering the polling interval option configuration.
Ohh, I see! No, it does. It's independent of the polling interval. "Retry all" simply gets all the failed jobs and puts them back into the queue. The queue backend is then responsible for polling these again, so the polling interval would apply here. However, polling means how often the workers check for new work. If there's new work all the time, they won't be stopping for 5 seconds, they'll continue to work all pending jobs until they're done. I don't know if this is what you're seeing, though.
Thank you, @rosa. Indeed, that's what I was looking for. I appreciate your help regarding this issue. I will look for another approach to resolve this.
As a newcomer to this feature, I've encountered something that I'm unsure whether it's an issue or simply a gap in my understanding. I've been utilizing jobs to invoke an API that has a rate limit. To avoid this limit, I've configured solid queue in the YAML file with a polling interval of 5 seconds.
When using this setup, everything functions as expected; however, occasionally, jobs fail. After fixing these failures, I attempt to retry the calls. It appears that the 'retry all' option dispatches all of them simultaneously, which triggers the rate limit once again. When I send a few of them individually, I don't encounter this issue.
I'm uncertain whether this could also impact the scheduled job, but it took me a lot to determine why I was experiencing this issue. The only explanation I can think of is that the 'retry all' function might not be considering the polling interval option configuration.