miguelgrinberg / flask-sock

Modern WebSocket support for Flask.
MIT License
272 stars 24 forks source link

Add WebSocketRequestCompleted exception for normal WebSocket closures #73

Open cafedeflore opened 7 months ago

cafedeflore commented 7 months ago

In relation to issue #64, under the configuration of running Flask with Gunicorn and Gevent, a StopIteration exception is not captured by Flask, but it enters the finally clause. Consequently, this exception is not caught higher up by Gunicorn's StopIteration handler. Referencing this section of Flask's codebase: Flask on GitHub. When error capturing tools like Sentry are used, this leads to the reporting of the exception. Is it possible to define this exception specifically, so that Sentry can easily ignore it, and to distinguish it from a normal StopIteration?

miguelgrinberg commented 7 months ago

I don't understand how this works. Gunicorn expects StopIteration to be raised as a signal that the request should be ended. You have changed the exception to a different one that nobody handles. To me this looks like it breaks all usages of gunicorn except the one you are interested in, which we already know that it is broken in gunicorn and not here.

The correct solution here is to make the gevent worker in gunicorn use the StopIteration exception, in the same way the threaded and eventlet workers do.

As I mentioned in #64, if you are interested in using gevent you can use it directly instead of through Gunicorn and you will not see this, as the StopIteration trick only applies to Gunicorn.