Gunicorn: 재현된 오래된 버그: 'Response' 개체에는 websockets가 있는 wsgi.py에 'status_code' 속성이 없습니다.

그것을 재현하는 간단한 예가 있습니까? 또한 가능하면 최신 마스터로 시도하십시오.

이전에 프로덕션 환경과 동일한 애플리케이션 코드인 로컬 개발 환경에서 여러 번 시도했지만 재현할 수 없습니다.

그리고 버전 19.9.0 릴리스 로그를 확인했습니다.관련된 항목을 찾지 못했습니다.
이 오류 로그를 보고 새로운 것을 찾으면 여기에 게시하겠습니다.

특히 클라이언트에서 웹 소켓 프로토콜로의 모든 연결을 강제할 때 이 문제가 있습니다. 내 설정은 BoWuGit과 동일합니다. 업그레이드 전에 폴링 프로토콜을 허용하면 표시되지 않지만 다른 오류가 발생합니다.
`
[오류] 요청 처리 오류 /socket.io/?EIO=3&transport=polling&t=MPHUoV&sid=cd64be7c940e474d8728b114c3fb9bbe

역추적(가장 최근 호출 마지막):
파일 "/usr/local/lib/python3.6/site-packages/gunicorn/workers/async.py", 56행, 핸들
self.handle_request(listener_name, req, 클라이언트, addr)

handle_request의 파일 "/usr/local/lib/python3.6/site-packages/gunicorn/workers/async.py", 107행
respiter = self.wsgi(환경, resp.start_response)

파일 "/usr/local/lib/python3.6/site-packages/flask/app.py", 1994행, __call__
self.wsgi_app(환경, start_response) 반환

파일 "/usr/local/lib/python3.6/site-packages/flask_socketio/__init__.py", 43행, __call__
시작_응답)

파일 "/usr/local/lib/python3.6/site-packages/engineio/middleware.sys"
py", 47행, __call__
반환 self.engineio_app.handle_request(환경, 시작_응답)

handle_request의 파일 "/usr/local/lib/python3.6/site-packages/socketio/server.py", 360행
반환 self.eio.handle_request(환경, 시작_응답)

handle_request의 파일 "/usr/local/lib/python3.6/site-packages/engineio/server.py", 279행
소켓 = self._get_socket(sid)

파일 "/usr/local/lib/python3.6/site-packages/engineio/server.py", 439행, _get_socket
raise KeyError('세션 연결이 끊겼습니다')
`
그러나 웹 소켓에 연결을 강제 실행했기 때문에이 오류가 다시 표시되지 않았기 때문에 서로 관련이 있다고 생각합니다.

eventlet 0.24.1을 사용할 때 gunicorn 19.9.0 및 Flask-socketIO 3.0.2에서도 이 문제가 발생합니다.

AttributeError: 'Response' 개체에 'status_code' 속성이 없습니다.

또한 다음 요구 사항과 함께 이 문제가 발생합니다.

Flask==1.0.2
gunicorn==19.5.0
python-socketio==2.0.0
eventlet==0.24.1

열린 소켓 연결이 있는 웹 브라우저를 닫을 때 오류 메시지:

 Error handling request /socket.io/?EIO=3&transport=websocket&sid=d43ec0ae0bb946debc51f1ca2e5b8a94
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/gunicorn/workers/async.py", line 52, in handle
    self.handle_request(listener_name, req, client, addr)
  File "/usr/lib/python2.7/dist-packages/gunicorn/workers/async.py", line 114, in handle_request
    resp.close()
  File "/usr/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 403, in close
    self.send_headers()
  File "/usr/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 319, in send_headers
    tosend = self.default_headers()
  File "/usr/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 300, in default_headers
    elif self.should_close():
  File "/usr/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 233, in should_close
    if self.status_code < 200 or self.status_code in (204, 304):
AttributeError: 'Response' object has no attribute 'status_code'

이 문제는 python-engineio 최신 버전에서 수정된 것 같습니다.

python-engineio 최신 버전(2.3.2)으로 테스트했지만 여전히 작동하지 않습니다.

이 문제에 대한 소식이 있습니까? Sentry-python을 사용할 때 동일한 오류가 발생합니다.

나는 같은 문제가있다

이벤트렛: 0.25.1
플라스크 소켓: 4.2.1
총기콘: 19.9.0

그것을 재현하는 방법? cna 당신은 간단한 예를 제공합니까?

나는 또한 그것을 재현하는 방법을 잘 모르겠지만 내 gunicorn 앱에서 페이지를 새로 고칠 때 자주 발생합니다.

같은 문제가 발생하고 내 환경은 @eazow 와 동일하지만 gunicorn == 20.0.4입니다.
버그 추적을 위해 센트리를 설치한 후 문제가 발생한 것 같습니다.
문제는 다음을 통해 재현할 수 있습니다.

1. 페이지 새로고침(새 페이지를 열지 않음)
2. 페이지 닫기

흥미롭게도 새 페이지를 열면 문제가 발생하지 않습니다. 이유는 확실하지 않습니다. 감사 해요!

@cowbonlin 과 같은 문제가 있습니다. 같은 gunicorn 버전도.

Sentry를 설치한 후 엄청난 양의 이 오류가 발생합니다. 우리가 센트리 이전에 오류를 추적하지 않았기 때문에 이것이 항상 발생했는지 여부를 말하기는 어렵습니다.

우리 서버의 실제 기능에 영향을 미치지 않는 것 같지만 이것은 엄청난 스팸일 뿐입니다.

우리도 같은 일을 겪고 있습니다. Sentry가 설치되었지만 비활성화되었습니다. 어떤 아이디어?

센트리가 설치된 것과 동일한 문제입니다.

센트리(비활성화 여부) 없이 재생산하는 예가 있습니까?

또한 네임스페이스 대신 수동으로 /api를 눌렀습니다.

또한 네임스페이스 대신 수동으로 /api를 눌렀습니다.

무슨 뜻인가요 ? 이 센트리와 관련이 있습니까?

또한 네임스페이스 대신 수동으로 /api를 눌렀습니다.

무슨 뜻인가요 ? 이 센트리와 관련이 있습니까?

아니요, 이것은 socket.io 네임스페이스와 관련이 있습니다. 제거를 시도했는데 제거한 후에도 오류가 발생합니다. 그러나 gunicorn 또는 nginx가 없는 로컬 컴퓨터에서 이 다른 오류가 발생합니다. 이는 관련이 있을 수 있습니다.

내 요구 사항은 다음과 같습니다.

sentry_sdk == 0.14.3
Flask_SocketIO == 4.2.1
eventlet == 0.25.1

이것은 서버 측의 flask-socketio 코드입니다.

socketio = SocketIO(engineio_logger=True, logger=True, debug=True, cors_allowed_origins="*", path='/socket.io')
...
socketio.init_app(app, async_mode="eventlet")

그리고 이것은 클라이언트 측의 React 소켓 io 코드입니다.

          this.socket = io.connect(`http://localhost:5000?info=${someInfo}`, {
            transports: ['websocket', 'polling'] // an attempt to keep polling as a fallback but start on websockets
          });

도움이 되는지 알려주세요. Ubuntu에서 오류는 위의 것과 같고 Windows에서 로컬로 다음과 같습니다.
```추적(가장 최근 호출 마지막):
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", 599행, handle_one_response
쓰기(b'')
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", 줄 491, 쓰기
발생 AssertionError("start_response() 전에 write()")
AssertionError: start_response() 전에 write()

위의 예외를 처리하는 동안 다른 예외가 발생했습니다.

역추적(가장 최근 호출 마지막):
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", 357행, __init__
self.handle()
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", 390행, 핸들
self.handle_one_request()
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", 466행, handle_one_request
self.handle_one_response()
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", 609행, handle_one_response
쓰기(err_body)
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", 줄 538, 쓰기
wfile.flush()
파일 "C:\ProgramData\Anaconda3\lib\socket.py", 607행, 쓰기 중
반환 self._sock.send(b)
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\greenio\base.py", 397행, 보내기
반환 self._send_loop(self.fd.send, 데이터, 플래그)
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\greenio\base.py", 384행, _send_loop
send_method(데이터, *args) 반환
ConnectionAbortedError: [WinError 10053] 호스트 컴퓨터의 소프트웨어에 의해 설정된 연결이 중단되었습니다.

위의 예외를 처리하는 동안 다른 예외가 발생했습니다.

역추적(가장 최근 호출 마지막):
fire_timers의 파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\hubs\hub.py", 라인 461
시간제 노동자()
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\hubs\timer.py", 59행, __call__
cb( 인수, * kw)
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\semaphore.py", 147행, _do_acquire
waiter.switch()
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\greenthread.py", 라인 221, 메인
결과 = 함수( 인수, * kwargs)
"C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py" 파일, 818행, process_request
proto.__init__(conn_state, self)
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", 359행, __init__
self.finish()
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", 732행, 완료
BaseHTTPServer.BaseHTTPRequestHandler.finish(자체)
파일 "C:\ProgramData\Anaconda3\lib\socketserver.py", 784행, 완료
self.wfile.close()
파일 "C:\ProgramData\Anaconda3\lib\socket.py", 607행, 쓰기 중
반환 self._sock.send(b)
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\greenio\base.py", 397행, 보내기
return self._send_loop(self.fd.send, 데이터, 플래그)
파일 "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\greenio\base.py", 384행, _send_loop
send_method(데이터, *인수) 반환
ConnectionAbortedError: [WinError 10053] 호스트 컴퓨터의 소프트웨어에 의해 설정된 연결이 중단되었습니다```

센트리가 완전히 비활성화되면 이 오류가 사라지는 것을 확인할 수 있습니다. gunicorn이 이것을 처리할 만큼 충분히 견고하다면 좋을 것입니다.

범프 @benoitc

센트리가 완전히 비활성화되면 이 오류가 사라지는 것을 확인할 수 있습니다. gunicorn이 이것을 처리할 만큼 충분히 견고하다면 좋을 것입니다.

Sentry의 FlaskIntegration 를 비활성화해도 오류가 사라집니다.

비슷한 행동을 보입니다. 프로덕션에서 New Relic을 사용하면 flask-socketio에서 이 오류가 발생합니다. 개발 시에는 flask-socketio가 초기화되기 전에 werkzeug 디버거 미들웨어를 로드해야 합니다(따라서 engineio의 wsgi 앱에는 적용되지 않음). 문제는 프로덕션에서 오류가 발생하는 것을 정말 원하지 않는다는 것입니다.

gunicorn 구성의 post_request에서 응답을 대체할 수 없지만 resp.status_code에 상태 코드를 강제로 적용하려고 했습니다. 그래도 걸리지 않았습니다.

이 오류는 Sentry의 FlaskIntegration을 Gunicorn 및 Flask-SocketIO와 함께 사용하여 재현할 수 있습니다. 빨리 해결 가능할까요?

@Canicio 우리는 오류를 제거하려고 시도했으며 통합을 비활성화한 후에도 오류가 지속된다고 생각했습니다.

누구든지 @benoitc 에 대한 공유 가능한 코드/최소한의 예가 있습니까?

확신하는:

import sentry_sdk
from flask import Flask
from flask_socketio import SocketIO
from sentry_sdk.integrations.flask import FlaskIntegration

sentry_sdk.init(
    dsn="https://[email protected]/0",
    integrations=[FlaskIntegration()]
)

app = Flask(__name__)
socketio = SocketIO(app)

@app.route('/')
def index():
    return '''
<script src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/2.2.0/socket.io.js"></script>
<script>
    var socket = io()
</script>

요구 사항:

flask
sentry-sdk[flask]
flask-socketio
eventlet

예제 gunicorn 구성:

bind = '[::]:4444'
worker_class = 'eventlet'
accesslog = '-'

/ 로드 시 웹 소켓에 연결됩니다. 웹 소켓 연결 해제 시(예: 다른 곳으로 이동, 새로 고침) 다음과 같은 예외가 생성됩니다.

[2020-09-23 07:24:49 +0000] [16303] [ERROR] Error handling request /socket.io/?EIO=3&transport=websocket&sid=29f4c1adfac343d6bc6db56acf8fd0ee
Traceback (most recent call last):
  File "/home/ziddey/projects/sentry/venv_sentry/lib/python3.8/site-packages/gunicorn/workers/base_async.py", line 55, in handle
    self.handle_request(listener_name, req, client, addr)
  File "/home/ziddey/projects/sentry/venv_sentry/lib/python3.8/site-packages/gunicorn/workers/base_async.py", line 115, in handle_request
    resp.close()
  File "/home/ziddey/projects/sentry/venv_sentry/lib/python3.8/site-packages/gunicorn/http/wsgi.py", line 402, in close
    self.send_headers()
  File "/home/ziddey/projects/sentry/venv_sentry/lib/python3.8/site-packages/gunicorn/http/wsgi.py", line 318, in send_headers
    tosend = self.default_headers()
  File "/home/ziddey/projects/sentry/venv_sentry/lib/python3.8/site-packages/gunicorn/http/wsgi.py", line 299, in default_headers
    elif self.should_close():
  File "/home/ziddey/projects/sentry/venv_sentry/lib/python3.8/site-packages/gunicorn/http/wsgi.py", line 219, in should_close
    if self.status_code < 200 or self.status_code in (204, 304):
AttributeError: 'Response' object has no attribute 'status_code'
2001:470:1f07:7eb:9dd4:254c:35d7:236c - - [23/Sep/2020:07:24:49 +0000] "GET /socket.io/?EIO=3&transport=websocket&sid=29f4c1adfac343d6bc6db56acf8fd0ee HTTP/1.1" 500 0 "-" "-"

참고: 저는 실제로 Sentry를 사용한 적이 없습니다. 이것은 센트리 시작 페이지에서 가져온 것입니다. dsn 예제는 우리 테스트에서 잘 작동합니다.

integrations=[FlaskIntegration()] 에 주석을 달면 오류가 제거됩니다(물론 효과적으로 보초를 비활성화함).

그만한 가치가 있기 때문에 오류 없이 eventlet 대신 gevent-websocket을 사용할 수 있습니다. 그러나 모든 요청을 처리하는 것 같습니다.

좋아, 좀 놀았어. Sentry/newrelic이 응답을 래핑하는 것 같습니다. Sentry가 없으면 예상한 대로 <eventlet.wsgi._AlreadyHandled object at 0x7fd0f5b1c0d0> 를 얻고 gunicorn의 EventletWorker.is_already_handled()가 반복을 중지합니다.

그러나 Sentry를 사용하면 대신 <sentry_sdk.integrations.wsgi._ScopedResponse object at 0x7f30155a5100> 와 같이 되어 확인에 실패합니다.

대신, 우리는 그것이 비어 있는지 확인하기 위해 respiter를 엿볼 수 있습니다. 내일은 더 지켜봐야 합니다.

좋습니다. 제가 생각해낸 해결 방법은 다음과 같습니다.

eventlet_fix.py:
아래 편집 참조

그리고 내 gunicorn config.py: worker_class = 'eventlet_fix.EventletWorker .

문제는 sentry/newrelic이 응답을 래핑하므로 eventlet의 ALREADY_HANDLED 에 대해 간단히 확인할 수 없다는 것입니다. 이미 처리된 요청의 특성은 gunicorn의 start_response 가 호출되지 않는다는 것이므로 대신 응답 상태가 있는지 확인할 수 있습니다.

그래서 wsgi 호출을 가로채어 응답 상태를 확인하고 필요에 따라 응답 값을 해킹했습니다. 이렇게 하면 요청이 여전히 gunicorn에 의해 기록될 수 있습니다. 대신 원래 동작을 유지하려면 StopIteration 를 대신 올릴 수 있습니다.

상태를 101로 해킹하는 것은 여기에서의 사용 사례(flask-socketio websocket)에 적합하지만, 그렇지 않으면 headers_sent 및 should_close 가 강제로 True로 지정되므로 None으로 두는 것도 괜찮습니다.

다시 말하지만, status 가 설정되지 않은 경우 start_response 가 호출되지 않았으므로 요청이 외부적으로 "이미 처리"되어 있어야 한다고 가정합니다.

편집 : 좋지 않습니다. 재평가할 필요가 있을 것입니다. 요청을 수행하는 데 시간이 걸리면 resp.status start_response 가 호출되지 않습니다.

edit2: 해킹된 응답 반복자가 있는 수정된 버전은 다음과 같습니다.

from functools import wraps

from gunicorn.workers.geventlet import EventletWorker as _EventletWorker


class HackedResponse:
    def __init__(self, respiter, resp):
        self.respiter = iter(respiter)
        self.resp = resp
        if hasattr(respiter, "close"):
            self.close = respiter.close

    def __iter__(self):
        return self

    def __next__(self):
        try:
            return next(self.respiter)
        except StopIteration:
            if not self.resp.status:
                self.resp.status = "101"  # logger derives status code from status instead of using status_code
                self.resp.status_code = 101  # not actually needed since headers_sent/force_close result in status_code not being checked anymore
                self.resp.headers_sent = True
                self.resp.force_close()
            raise


def wsgi_decorator(wsgi):
    @wraps(wsgi)
    def wrapper(environ, start_response):
        respiter = wsgi(environ, start_response)
        resp = start_response.__self__
        return HackedResponse(respiter, resp)

    return wrapper


class EventletWorker(_EventletWorker):
    def load_wsgi(self):
        super().load_wsgi()
        self.wsgi = wsgi_decorator(self.wsgi)

분명히 이것은 단지 원숭이 패치입니다. 실제 수정은 잠재적으로 base_async.py의 handle_request 에 포함될 수 있습니다. 핵심은 resp.status ( start_response 호출됨) 또는 resp.headers_sent 을 확인하여 respiter 를 반복한 후 start_response 가 호출되었는지 (간접적으로) 확인하는 것일 수 있습니다. resp.headers_sent (요청에 실제로 응답했다는 확인).

@benoitc
@ziddey 가 문제를 해결할 방법을 찾았습니다.

@ziddey 귀하의 예에 대한 빠른 질문(저는 센트리를 사용하지 않기 때문에).

• 오류가 센트리에만 영향을 미치거나 요청도 중지되었습니까? 예를 들어 작업자가 종료 중입니까(응답이 래핑된 경우 그럴 것으로 의심됨)?
• 응답이 포장되어 있어도 요청을 정리하거나 무언가를 포장할 것으로 예상하십니까?

@benoitc 는 현재 테스트할 수 없지만 https://github.com/benoitc/gunicorn/issues/1852#issuecomment -697189261 및 https://github.com/benoitc/gunicorn/blob/4ae2a05c37b332773957f90 위의 역추적을 보고 있습니다.

일반적으로 is_already_handled 는 True를 반환하고 여기서 끝납니다.

그러나 응답이 래핑되기 때문에 해당 방법은 작동하지 않습니다. 대신 실행이 진행되고 115행에서 ​​실패합니다. resp.close() 헤더 전송을 시도하지만 start_response 가 호출되지 않았으므로 상태 코드가 없습니다. 그렇게 되더라도 결국 분명히 실패할 것입니다.

그 결과 handle_error 에 의해 다시 발생하고 처리되는 AttributeError 가 발생합니다. 요청은 이미 외부에서 처리되었으므로 여기에는 로그 스팸 외에는 아무런 해가 없습니다.

나는 Sentry에 대해 너무 많이 말할 수 없습니다. 저도 사용하지 않습니다.

그러나 한 가지 세부 사항은 현재 이미 처리된 메커니즘으로 인해 액세스 로깅이 발생하지 않는다는 것입니다. 외부에서 어떻게 처리되었는지 알 수 있는 방법이 없기 때문에 이것이 기술적으로 의미가 있다고 생각합니다. 해킹된 응답에서 상태 코드를 101로 설정하고 headers_sent 를 True로 설정하여 핸들러가 계속 진행되고 요청에 대한 액세스가 계속 기록됩니다.

resp.status 를 확인하는 것은 start_response 가 호출되었는지 확인하기 위한 최종 테스트입니다.

@benoitc 가 이것을 다시 방문합니다. 요청이 이미 처리되었다는 결론을 내리기 위해 environ['gunicorn.socket'] 대신 기본 개체에 대한 일종의 프록시가 될 수 있습니다. 그렇게 하면 소켓에 직접 액세스할 때 기록될 수 있고(예: eventlet에 대해 get_socket() 래핑) is_already_handled 와 같은 용도로 사용될 수 있습니다.

액세스 로깅이 필요한 경우에도 여전히 응답 상태를 해킹해야 합니다.