-
-
Notifications
You must be signed in to change notification settings - Fork 78
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
Disconnect event is not propogated to the middleware while a request is processing #286
Comments
@speksen-kb01 yes, at the moment the network I/O in Granian doesn't allow to be notified when connection gets closed prematurely by clients. In fact, network I/O in Granian today is eager, meaning checks over connection state are run only when actually reading and writing: if you change the code to try writing back empty contents during that 10 seconds, you should be able to get the exception you're looking for. This might be changed in the future – if a valid reason to change the current behaviour exists – but it really depends on the lower library capabilities. |
Imagine that the endpoint is something that consumes too much resource and it can be called multiple times by a single client in parallel. In order not to waste resource we want to cancel as soon as we receive a disconnect event |
I see, thanks for the explanation. For the use case part, Imagine a "request chain" that depend on each other to finish, and it takes some time, for each to finish it's task. |
Just to clarify on this: this seems to be not achievable due to how Hyper is currently designed. |
I don't really know the intricacies of the granian project, so I dont know if this could help but I'd like to also add that hyper seems to drop the request task upon a disconnect. Could be related to this issue somehow: |
This issue was closed as inactive #324 but I think it relates to this. The original author probably got jack of granian and went back to something stable like gunicorn/uwsgi. I manage multiple django projects accross various organisations. One of them we stuck with granian but put connection timeouts on the postgresql server - this fixed the issue. One of them we went back to unicorn because the system admin insisted it wasn't his systems problem and didn't want to change anything if it "wasn't his fault" - not that it was but the postgresql server timeouts would have worked also. Either way, it would be good if this could be resolved. |
Definitely not related, even if you're using ASGI with Django. |
thanks for confirmation, can you please explain what the actual issue is for django though so I understand? |
Django uses the |
Thank you, will the --backpressure argument still be required for this to take effect? Would it be possible to please include an example usage in the releases/changelog for 1.4.4? |
Backpressure is still needed, the usage is the same for all the 1.4.x releases. |
Hello,
We were working on an HttpDisconnectMiddleware, which would cancel the ongoing tasks when user cancels the requests.
We were using this same middleware with other servers like uvicorn and hypercorn, which would trigger the exception upon cancellation, but in the case of granian, it seems like the disconnect event is queued and not sent to the middleware, and only sent to it after the task finishes.
I've created a repo for showcasing the effect,
https://github.com/speksen-kb01/fastapi-disconnect-example
Is there a reason why we couldn't get the event while a request is being processed? If so, what do you think it is related to and is it fixable by changing the middleware to some extent?
Funding
The text was updated successfully, but these errors were encountered: