Improve on-retry logging about tenacity HOT 6 CLOSED

I'd like to have more advanced logging or more generalized before/after callbacks.

It would be nice to:

• Access exception information (exc_info) in the after callback, if any.
• Access all function arguments in after. Right now, only the function itsself is given.

from tenacity.

So I may be misunderstand the discussion here. Is the consensus that currently there exists no way to print the exception? Or is one known?

I looked through the code, and it seems to to not be possible. The before_sleep callback is the only one that has access to the exception, via last_result, but, notably, not exc_info, which we'd need to actually print the traceback, only the exception instance itself..

from tenacity.

I guess you can more or less do everything here already, but I admit it might not be obvious.

The last thing I want is a gigantic patch for this use case, but if you can enhance the current code and function and just add generic stuff so that's possible to do, give it a try. :)

from tenacity.

The current state is sort of awkward for several reasons:

• The retry may not be configured to sleep so the name is unintuitive
• Assumes that an exception will be the cause of retries, but you can change this (e.g. retry=retry_if_result(is_false_p)). It doesn't crash, but it does print the nonsensical message Retrying __main__.do_something_unreliable in 0 seconds as it raised None. which misidentifies the reason for the retry.
• The final exception before a stop isn't printed, but it is reraised so not really a deal-breaker, just awkward because the logging won't be consistent.
• The traceback isn't printed which is often really useful.

Instead, it would be nice to have an after_exception hook that would log the exception and optionally the traceback and change the before_sleep hook to simply state how long the sleep will be and not attempt to log the reason for the retry/sleep unless it can be fixed for the case where the retry reason is changed.

from tenacity.

Well the whole reason for the callbacks is that you can define your own behaviour. So if you find it awkward that the traceback is not printed, you can define a callback that would print the traceback (Point 4). Or define a callback that prints a more sensible message (Point 2). The included callbacks should only serve as examples.

Point 3 is not real an issue in my mind because the callback name is "before_sleep" and shouldn't be called on the final exception.

Point 1 is valid I think, but it is the best name I came up with :-)

from tenacity.

With #122, #124 and #126 landed all callbacks now have access to retry_state which contains all information related to current retry call. I'm closing this.

from tenacity.