-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Old bug reproduced:'Response' object has no attribute 'status_code' in wsgi.py with websockets #1852
Comments
do you have any simple example to reproduce it? Also please try with latest master if possible. |
Previously I have tried several times in my local development environment,which is the same application code with production environment,but I can't reproduce it. And I have checked version 19.9.0 release log,not found something related,I'll keep |
I too have this problem, specifically when I force all my connection from client to websocket protocol. My settings is the same as BoWuGit. If allow polling protocol before upgrade, this does not show up, but another error : Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/gunicorn/workers/async.py", line 107, in handle_request File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1994, in call File "/usr/local/lib/python3.6/site-packages/flask_socketio/init.py", line 43, in call File "/usr/local/lib/python3.6/site-packages/engineio/middleware. File "/usr/local/lib/python3.6/site-packages/socketio/server.py", line 360, in handle_request File "/usr/local/lib/python3.6/site-packages/engineio/server.py", line 279, in handle_request File "/usr/local/lib/python3.6/site-packages/engineio/server.py", line 439, in _get_socket |
Having this issue as well with gunicorn 19.9.0 and Flask-socketIO 3.0.2, when using eventlet 0.24.1
|
Also experiencing this issue with the following requirements:
Error message when closing web browser that has open socket connection:
|
It looks like this issue has been fixed in the latest version of python-engineio.. |
Have tested with python-engineio latest version(2.3.2), still not work. |
Any news on this issue? I get the same error when using sentry-python |
how to reproduce it? cna you provide a simple example? |
i'm also not sure how to reproduce it, but it happens OFTEN when i refresh a page on my gunicorn app |
Encounter the same issue, and my environment is the same as @eazow while gunicorn == 20.0.4.
Interestingly, opening a new page won't produce the issue. Not sure why. Thanks! |
I have the same issue as @cowbonlin . Same gunicorn version, too. After installing sentry, we're getting crazy amounts of this error. Though I find it hard to tell if this always happened or not - since we didn't track errors before sentry. While it doesn't seem to influence actual functionality of our server, this is just a ton of spam. |
We're experiencing the same. Sentry installed but disabled. Any ideas? |
Same issue with sentry installed. |
Do you hve any example that reproduce it without sentry (disabled or not) ? |
In addition, instead of a namespace I manually hit /api. |
what does it mean ? Is this sentry related? |
No, this is related to socket.io namespaces. I tried removing them, and even after removing them, I get the error. I get this other error on local machine without gunicorn or nginx however, which may be related. These are my requirements:
This is my flask-socketio code on the server side:
And this is my React socket io code on the client side:
Let me know if this helps. On Ubuntu the error looks like the above one, and locally on Windows it looks like this:
|
Can confirm this error disappears when sentry is fully disabled. Would be great if gunicorn was robust enough to deal with this. |
Bump @benoitc |
I found that disabling the Sentry's |
Seeing similar behavior. Using New Relic in production causes this error with flask-socketio. In development, the werkzeug debugger middleware needs to be loaded before flask-socketio is initialized (so it's not applied to engineio's wsgi app). Problem is production is where I really don't want the errors tripping. Can't replace the response in gunicorn config's post_request, but I tried forcing a status code onto resp.status_code. It didn't take though. |
This error is reproducible by using Sentry's FlaskIntegration together with Gunicorn and Flask-SocketIO. Is it possible to solve it soon? |
@Canicio we thought to try that to get rid of the error and even after disabling the integration, the error persists. |
Does anyone have sharable code/a minimal example for @benoitc to go off of? |
Sure:
requirements:
example gunicorn config:
On loading
Note: I've never actually used sentry myself. This is just from the sentry getting started page. The example Commenting For what it's worth, gevent-websocket can be used instead of eventlet without errors. However, it then seems to handle all requests.. |
Ok, did some playing around. Looks like sentry/newrelic wraps the response. Without sentry, we get However, when using sentry, this becomes something like Instead, we could peek at respiter to see if it's empty. Will look further tomorrow. |
Alright, here's the workaround I've come up with: eventlet_fix.py: And in my gunicorn config.py: The issue is that sentry/newrelic wraps the responses, so we can't simply check it against eventlet's So I've hijacked the wsgi call to then check for a response status, and hack response values as necessary. This allows the request to still be logged by gunicorn. If instead, it's desired to keep the original behavior, Hacking the status to 101 is appropriate for our use case here (flask-socketio websocket), but otherwise, leaving it as None works as well since Again, this makes the assumption that if edit: No good. Will need to reevaluate. If the request takes time to perform, edit2: Here's a fixed version with a hacked response iterator:
Obviously this is just a monkey patch. The actual fix could potentially go in |
@ziddey quick questions for your example (as I am not using sentry).
|
@benoitc not able to test currently, but looking at the traceback above #1852 (comment) and gunicorn/gunicorn/workers/base_async.py Lines 107 to 140 in 4ae2a05
Normally, However, because the response is wrapped, that method doesn't work. Instead, execution progresses, failing at line 115: This results in an AttributeError that gets reraised and assumedly handled by I can't say too much about Sentry-- I'm not using it either. One detail though: the current already-handled mechanism results in no access logging. I suppose this technically makes sense since there's no way of knowing how it was handled externally. In my hacked response, I force the status code to 101, with Checking |
@benoitc revisiting this. To more definitively conclude that the request was already handled, It would still require hacking a response status though if access logging is desired. |
Same issue is happening using gthread. Instance started using:
Gunicorn 20.1.0 with Python 3.8.12 |
Getting same error after changing worker class to gthread #1852 (comment). Any updates on this one ? |
Just like this old issue 1210 said, gunicorn logs error when client disconnects, and my environment is:
Debian GNU/Linux 7.8
nginx
Python3.4
gunicorn(19.8.1) (with one or multiple workers)
Flask-SocketIO, client specifies websocket transport
Everything works well including clients, except for this error log, two cloud independent production instances both persistently logs,but I can't reproduce it in my develop machine, which is a mac.
Much thanks for your help.
The text was updated successfully, but these errors were encountered: