-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better request cancel handling #2513
Conversation
Codecov ReportBase: 87.834% // Head: 87.844% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #2513 +/- ##
=============================================
+ Coverage 87.834% 87.844% +0.009%
=============================================
Files 78 78
Lines 6461 6466 +5
Branches 1246 1247 +1
=============================================
+ Hits 5675 5680 +5
Misses 560 560
Partials 226 226
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
It looks good to me. Let's make it ready and run the CI? |
I need to add a few more unit tests. |
Did you check how this affects ASGI, or how are connections lost with that anyway? The catching/handling logic in Sanic is extremely complicated but I see that you did a change to http1 but not to asgi, while both often need identical changes. |
Currently, there is no way to distinguish between the following:
SCENARIO A: Something in the handler raises a
CancelledError
SCENARIO B: A client cancels a request in the middle of handling
This is particularly noticeable and troublesome if there is an underlying library (like a DB driver) that decides to call
CancelledError
. It causes a 503 and there really is no way to catch this. The following will NOT work, which is somewhat counterintuitive.The idea here is to introduce a new exception:
RequestCancelled
that will bubble up through the system. It should be catchable on its own, and alsoCancelledError
should also be catchable. Furthermore, it should not create a response object and attempt to push the bytes if the client connection has been lost.