Open apurvis opened 6 years ago
An important thing to note here: Technically, does_not_retry
is a function that returns a generator, as you can see here:
>>> def foo():
... for i in range(2):
... yield i
...
>>> type(foo)
<type 'function'>
>>> type(foo())
<type 'generator'>
In your second example, does_not_retry
isn't a generator function, because it doesn't contain yield
anywhere. Thus, tenacity
restarts it just fine.
The way generator functions work is that Python turns does_not_retry
into something that, when executed, returns an iterable that executes the code inside does_not_retry
. Weird, I know, but humor me for a second. So now we have two objects (ish); the generator that handles executing code, and then the actual code itself (what's inside does_not_retry
). I'll refer to the executing stuff you care about as the "user's code".
Now suppose an exception occurs the user's code somewhere. tenacity.retry()
wrapped the generator function, not the generator itself (i.e. the user's code). Thus, the exception propagates up.
Is this issue duplicate with #64 ?
Not a duplicate so much as a use case for #64.
So let me preface this by saying that I tried to code up a minimal example that showed retries not happening, and I couldn't get it to not work... so I'm very confused.
Code that was not retrying basically looks like this:
client.get_collection
is a function that is a generator, so there's sort of a nested generator thing going on, and it is from within that method that theRateLimitExceeded
exception springs that i want to retry.Is there any reason this would not work? This is the minimal example I coded up to try to show it not working, but it worked fine: