You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, thanks for reaching out, I think it was intentional.
If we cancel the request on CancelledError due to timeout, we will lose the chance to get the response for the ongoing request and we will need to restart it again later if we still need it.
For example, a query takes a timeout of 3.0s by default, and if it contains 2 requests, each taking 2s, then the query will time out on the second request, and your question is, whether the second request should be canceled.
If the request is canceled, and later the user retries, we still have to resend the request, and it's likely to fail again. But if the request is shielded and it continues to wait for a full timeout (3.0s) as an independent query, it will finally succeed and update the cache. So when the user retries, we can provide the cached response immediately.
Our problem is that a program that should terminate (due to an exception) instead hangs forever, apparently because one or more asyncio task cancellations failed due to try blocks that stop the raise of asyncio.CancelledError.
That being said, we are not sure if specifically async_dns is causing the problem.
gera2ld
changed the title
Suppressing CancelledError
[feature] Add an option to suppress CancelledError
Jan 25, 2023
Hello,
In
recursive_resolver.py
there is atry
block that we suspect could be preventing some cancelled programs from actually exiting:If a
asyncio.CancelledError
is thrown on line 145, it would be supressed by theexcept
clause. Isn't this an issue? Or is it intentional?In case it's an issue, a possible solution would be to add the following two lines above the
except
in line 147:Thanks.
The text was updated successfully, but these errors were encountered: