Summary
The exponential backoff in a task's loop is not reset when an iteration of the task succeeds, making even rare failures make it wait for a large time.
Reproduction Steps
- Create a coroutine that succeeds most times but fails in some occasions with an expected exception
- Decorate the coroutine with the discord.ext.tasks.loop method and let it run
Minimal Reproducible Code
do_fail = True
@tasks.loop(seconds=1)
async def fails_sometimes:
global do_fail
print("Hi")
if do_fail:
raise aiohttp.ClientError()
do_fail = False
else:
do_fail = True
fails_sometimes.start()Expected Results
The coroutine runs each second (plus the initial backoff time after each failure)
Actual Results
The coroutine waits exponentially more time after each failure, even though the failures are separated by successful executions.
Intents
None
System Information
- Python v3.10.12-final
- py-cord v2.4.1-final
- aiohttp v3.9.1
- system info: Linux 5.15.0-1070-raspi #73-Ubuntu SMP PREEMPT Thu Dec 19 17:56:10 UTC 2024
Checklist
Additional Context
I am not sure if this is indeed a bug or if it is the intended behaviour, but it seems to me that making a task that has had many iterations wait for more and more time after failures not matter how many successful iterations have been executed between those failures is not a reasonable behaviour.
A simple fix would be to reset the ExponentialBackoff object after a successful iteration, I have done it and tested it in 06458c2. If this is indeed not the expected/reasonable behaviour, I can make a pull request with this change. And in either case, I think it would be a good idea to explicitly document the backoff behaviour when the connect argument is set to True.
Summary
The exponential backoff in a task's loop is not reset when an iteration of the task succeeds, making even rare failures make it wait for a large time.
Reproduction Steps
Minimal Reproducible Code
Expected Results
The coroutine runs each second (plus the initial backoff time after each failure)
Actual Results
The coroutine waits exponentially more time after each failure, even though the failures are separated by successful executions.
Intents
None
System Information
Checklist
Additional Context
I am not sure if this is indeed a bug or if it is the intended behaviour, but it seems to me that making a task that has had many iterations wait for more and more time after failures not matter how many successful iterations have been executed between those failures is not a reasonable behaviour.
A simple fix would be to reset the ExponentialBackoff object after a successful iteration, I have done it and tested it in 06458c2. If this is indeed not the expected/reasonable behaviour, I can make a pull request with this change. And in either case, I think it would be a good idea to explicitly document the backoff behaviour when the connect argument is set to True.