Support for retry event hook#50
Support for retry event hook#50bodenr wants to merge 6 commits intorholder:masterfrom bodenr:retry_log_hook
Conversation
It's very common for consumers to perform some action on each attempt iteration; for example logging a message that the operation failed and a retry will be performed after some time. While this can be done today using a custom wait_func, it's inconvenient to use a partial to wrap an existing retrying sleep function just to get this behavior. This patch adds support for a new kwarg called wait_event_func that when passed should reference a function to be called before sleeping for another attempt iteration. This function looks similar to retrying wait_funcs except its first arg is the time to sleep as returned by the current 'wait' function. A handful of unit tests are also included.
It's very common for consumers to perform some action on each attempt iteration; for example logging a message that the operation failed and a retry will be performed after some time. While this can be done today using a custom wait_func, it's inconvenient to use a partial to wrap an existing retrying sleep function just to get this behavior. This patch adds support for a new kwarg called wait_event_func that when passed should reference a function to be called before sleeping for another attempt iteration. This function looks similar to retrying wait_funcs except its first arg is the time to sleep as returned by the current 'wait' function. A handful of unit tests are also included.
No assertIsNotNone() in py26 so change to a py26 compatible assert statement.
|
LGTM, feel free to rebase! |
…nto retry_log_hook Conflicts: test_retrying.py
|
travis didn't rebuild; let me try closing + reopening this |
Conflicts: AUTHORS.rst retrying.py test_retrying.py
|
@jd looks like this one is clean now. |
|
Seems pretty useful to me 👍 |
|
Looks redundant with wait_func, no? |
|
@jd perhaps. As indicated in the "commit message" its very common to want a "callback" per retry (for something like logging a message). While this could be done with a custom wait_func it inconvenient to decorate and provide a custom wait_func just for this purpose. That said the intent here is to simplify that consumption pattern. |
|
I think we don't want to clutter more the init func. What about providing that functionality as part of a custom wait_func that would be provided by retrying itself? Possibly a composable class. |
|
@jd @harlowja Using this approach it's easy to just pass my "hook function" as the wait_func to achieve what I need. It also address the "chaining" TODO in the code if I understand properly. I haven't see #55 yet, so perhaps we can weight pros/cons of it vs. the |
3 participants
It's very common for consumers to perform some action on each
attempt iteration; for example logging a message that the operation
failed and a retry will be performed after some time. While this can
be done today using a custom wait_func, it's inconvenient to use
a partial to wrap an existing retrying sleep function just to get this
behavior.
This patch adds support for a new kwarg called wait_event_func
that when passed should reference a function to be called
before sleeping for another attempt iteration. This function
looks similar to retrying wait_funcs except its first arg is
the time to sleep as returned by the current 'wait' function.
A handful of unit tests are also included.