- Notifications
You must be signed in to change notification settings - Fork152
Feature custom delay between attempts#221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Feature custom delay between attempts#221
Uh oh!
There was an error while loading.Please reload this page.
Conversation
coveralls commentedJan 10, 2020
| backoff=delay_settings(self.attempts)ifcallable(delay_settings)elsedelay_settings | ||
| assertisinstance(backoff,int), \ | ||
| "BACKGROUND_TASK_DELAY_BETWEEN_ATTEMPTS must be an integer or a callable that returns an integer. " \ | ||
| "Got %s (%s)."% (backoff,type(backoff).__name__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
It is convenient to specify the type of the invalid setting or result of the callable, because a string value in settings (like '1') would result in the following message:
"BACKGROUND_TASK_DELAY_BETWEEN_ATTEMPTS must be an integer or a callable that returns an integer. Got 1."# '1' would not be single quoted in that case.
Better get an explicit:
"BACKGROUND_TASK_DELAY_BETWEEN_ATTEMPTS must be an integer or a callable that returns an integer. Got 1 (str)."... hence the need to avoid shadowing thetype built-in function in the parameter.
| self.assertEqual(CompletedTask.objects.count(),0) | ||
| self.assertTrue(next_run_at_before<task.run_at<next_run_at_after) | ||
| @skipIf(settings.BACKGROUND_TASK_RUN_ASYNC,"assertRaises not working when async.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I could not have the context
withself.assertRaises(AssertionError):pass
work in async mode.
Any hint ?
| Task errors | ||
| =========== | ||
| Tasks are retried if they fail and the error recorded in last_error (and logged). A task is retried as it may be a temporary issue, such as a transient network problem. However each time a task is retried it is retried later and later, using an exponential back off, based on the number of attempts: | ||
| ..code-block::python | ||
| (attempts**4)+5 | ||
| This means that initially the task will be tried again a few seconds later. After four attempts the task is tried again 261 seconds later (about four minutes). At twenty five attempts the task will not be tried again for nearly four days! It is not unheard of for a transient error to last a long time and this behavior is intended to stop tasks that are triggering errors constantly (i.e. due to a coding error) form dominating task processing. You should probably monitor the task queue to check for tasks that have errors. After ``MAX_ATTEMPTS`` the task will be marked as failed and will not be rescheduled again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Seemed better to raise the subject of Task Error before the settings variables.
ghost commentedApr 9, 2020
Is it possible to validate this pull request? I need this too |
The default repeating delay between task errors is very interesting but for the sake of consistency between our apps, we need to set a fixed delay of 15 minutes.
In order to keep the original feature and to allow more control on the delay, this PR adds a new setting variable (named
BACKGROUND_TASK_DELAY_BETWEEN_ATTEMPTS), along with the suitable unit tests. The documentation has also been updated.