-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
we shouldn't process requests where the requester has timed out/gone away #3528
Comments
a nice way to do this might be via cancellation of Deferreds? |
keywords, since I just spent 10 minutes searching for this: cancel, disconnect |
Cancelling Deferreds to abort processing looks very promising! How Deferred.cancel() worksWhen The coroutine may then deal with the CancelledError using normal exception handling. The Deferred wrapping the coroutine will not automatically fail with a CancelledError unless it bubbles up through the coroutine. asyncio has a similar feature, where an ComplicationsUnfortunately aborting processing of requests isn't as simple as calling
Perhaps we could limit cancellation to a handful of interesting endpoints, like |
yeah it might be good to start this with one endpoint, and work from there. |
In general, for some code to support cancellation:
Checking all of this usually involves exploring all TODOIn the call trees below, an [x] means that a function has been checked to handle cancellation correctly and that all its ✔️ The
|
I did some exploration of how we'd test cancellation of entire endpoints at #12674. |
Given that all the groundwork is done here, I don't think keeping this issue open any longer is much use. We can add cancellation support to other APIs as and when it turns out to be useful. |
when we get busy, sometimes we queue up requests, which means that once we get round to processing them, there is no point in doing so. See #3444 for a good example.
The text was updated successfully, but these errors were encountered: