Gunicorn: पुराने बग को पुन: प्रस्तुत किया गया：'प्रतिक्रिया' वस्तु में websockets के साथ wsgi.py में कोई विशेषता 'status_code' नहीं है

क्या आपके पास इसे पुन: पेश करने के लिए कोई आसान उदाहरण है? कृपया यदि संभव हो तो नवीनतम मास्टर के साथ प्रयास करें।

पहले मैंने अपने स्थानीय विकास पर्यावरण में कई बार कोशिश की है, जो उत्पादन वातावरण के साथ एक ही एप्लिकेशन कोड है, लेकिन मैं इसे पुन: पेश नहीं कर सकता।

और मैंने संस्करण 19.9.0 रिलीज़ लॉग की जाँच की है，कुछ संबंधित नहीं मिला，मैं रखूँगा
इस त्रुटि लॉग को देख रहे हैं, अगर कुछ नया मिल जाए तो मैं यहां पोस्ट करूंगा।

मुझे भी यह समस्या है, खासकर जब मैं क्लाइंट से वेबसोकेट प्रोटोकॉल के लिए अपने सभी कनेक्शन को मजबूर करता हूं। मेरी सेटिंग्स BoWuGit जैसी ही हैं। यदि उन्नयन से पहले मतदान प्रोटोकॉल की अनुमति है, तो यह दिखाई नहीं देता है, लेकिन एक और त्रुटि है:
`
[त्रुटि] अनुरोध को संभालने में त्रुटि /socket.io/?EIO=3&transport=polling&t=MPRHUoV&sid=cd64be7c940e474d8728b114c3fb9bbe

ट्रेसबैक (सबसे हालिया कॉल अंतिम):
फ़ाइल "/usr/local/lib/python3.6/site-packages/gunicorn/workers/async.py", लाइन 56, हैंडल में
self.handle_request (श्रोता_नाम, अनुरोध, ग्राहक, योजक)

फ़ाइल "/usr/local/lib/python3.6/site-packages/gunicorn/workers/async.py", लाइन 107, हैंडल_रेक्वेस्ट में
रेस्पिटर = 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__ में
start_response)

फ़ाइल "/usr/local/lib/python3.6/site-packages/engineio/middleware.
py", लाइन 47, __call__ में
वापसी self.engineio_app.handle_request(environ, start_response)

फ़ाइल "/usr/local/lib/python3.6/site-packages/socketio/server.py", लाइन 360, हैंडल_रेक्वेस्ट में
वापसी self.eio.handle_request(environ, start_response)

फ़ाइल "/usr/local/lib/python3.6/site-packages/engineio/server.py", लाइन 279, हैंडल_रेक्वेस्ट में
सॉकेट = स्वयं._get_socket (एसआईडी)

फ़ाइल "/usr/local/lib/python3.6/site-packages/engineio/server.py", लाइन 439, _get_socket में
KeyError बढ़ाएँ ('सत्र डिस्कनेक्ट हो गया है')
`
लेकिन मुझे संदेह है कि इसका एक-दूसरे के साथ कुछ लेना-देना हो सकता है, क्योंकि मैं कनेक्शन को वेबस्केट होने के लिए मजबूर करता हूं, यह त्रुटि फिर से नहीं देखी गई है।

इवेंटलेट 0.24.1 का उपयोग करते समय गनिकोर्न 19.9.0 और फ्लास्क-सॉकेटियो 3.0.2 के साथ भी यह समस्या होना

विशेषता त्रुटि: 'प्रतिक्रिया' ऑब्जेक्ट में कोई विशेषता नहीं है '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'

ऐसा लगता है कि इस समस्या को अजगर-इंजीनियो के नवीनतम संस्करण में ठीक कर दिया गया है ..

पायथन-इंजीनियो नवीनतम संस्करण (2.3.2) के साथ परीक्षण किया है, फिर भी काम नहीं कर रहा है।

इस मुद्दे पर कोई खबर? संतरी-अजगर का उपयोग करते समय मुझे वही त्रुटि मिलती है

मेरे साथ भी वही दिक्कत है

घटना: 0.25.1
फ्लास्क-सॉकेटियो: 4.2.1
गनिकोर्न: 19.9.0

इसे कैसे पुन: पेश करें? cna आप एक साधारण उदाहरण प्रदान करते हैं?

मुझे यह भी नहीं पता कि इसे कैसे पुन: पेश किया जाए, लेकिन ऐसा अक्सर होता है जब मैं अपने गनिकोर्न ऐप पर एक पेज रीफ्रेश करता हूं

एक ही समस्या का सामना करें, और मेरा वातावरण @eazow जैसा ही है जबकि gunicorn == 20.0.4।
ऐसा लगता है कि बग ट्रैकिंग के लिए संतरी स्थापित करने के बाद यह समस्या हुई।
मुद्दों को द्वारा पुन: प्रस्तुत किया जा सकता है

1. पृष्ठ को ताज़ा करना (नया पृष्ठ नहीं खोलना)
2. पेज बंद करना

दिलचस्प बात यह है कि एक नया पृष्ठ खोलने से समस्या उत्पन्न नहीं होगी। यकीन नहीं है कि क्यों। धन्यवाद!

मेरे पास @cowbonlin जैसा ही मुद्दा है। वही गनिकोर्न संस्करण भी।

संतरी स्थापित करने के बाद, हम इस त्रुटि की पागल मात्रा प्राप्त कर रहे हैं। हालांकि मुझे यह बताना मुश्किल लगता है कि यह हमेशा होता है या नहीं - चूंकि हमने संतरी से पहले त्रुटियों को ट्रैक नहीं किया था।

हालांकि यह हमारे सर्वर की वास्तविक कार्यक्षमता को प्रभावित नहीं करता है, यह सिर्फ एक टन स्पैम है।

हम वही अनुभव कर रहे हैं। संतरी स्थापित लेकिन अक्षम। कोई विचार?

संतरी के साथ एक ही मुद्दा स्थापित।

क्या आपके पास कोई उदाहरण है जो इसे संतरी (अक्षम या नहीं) के बिना पुन: पेश करता है?

इसके अलावा, नामस्थान के बजाय मैंने मैन्युअल रूप से/एपीआई मारा।

इसके अलावा, नामस्थान के बजाय मैंने मैन्युअल रूप से/एपीआई मारा।

इसका मतलब क्या है ? क्या यह संतरी संबंधित है?

इसके अलावा, नामस्थान के बजाय मैंने मैन्युअल रूप से/एपीआई मारा।

इसका मतलब क्या है ? क्या यह संतरी संबंधित है?

नहीं, यह socket.io नेमस्पेस से संबंधित है। मैंने उन्हें हटाने की कोशिश की, और उन्हें हटाने के बाद भी, मुझे त्रुटि मिलती है। मुझे यह अन्य त्रुटि स्थानीय मशीन पर बिना गनिकोर्न या nginx के मिलती है, जो संबंधित हो सकती है।

ये मेरी आवश्यकताएं हैं:

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

यह सर्वर साइड पर मेरा कुप्पी-सॉकेटियो कोड है:

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

और यह क्लाइंट साइड पर मेरा रिएक्ट सॉकेट 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
          });

मुझे बताएं क्या इससे मदद मिलती है। उबंटू पर त्रुटि उपरोक्त की तरह दिखती है, और स्थानीय रूप से विंडोज़ पर ऐसा दिखता है:
``` ट्रेसबैक (सबसे हालिया कॉल अंतिम):
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", लाइन 599, handle_one_response में
लिखें (बी '')
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", लाइन 491, लिखित में
AssertionError ("लिखें () start_response ()") से पहले बढ़ाएं
अभिकथन त्रुटि: start_response () से पहले लिखें ()

उपरोक्त अपवाद को संभालने के दौरान, एक और अपवाद हुआ:

ट्रेसबैक (सबसे हालिया कॉल अंतिम):
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", लाइन 357, __init__ में
स्वयं संभाल ()
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", लाइन 390, हैंडल में
self.handle_one_request ()
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", लाइन 466, हैंडल_ऑन_रेक्वेस्ट में
self.handle_one_response ()
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", लाइन 609, handle_one_response में
लिखें (गलती_बॉडी)
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", लाइन 538, लिखित में
wfile.flush ()
फ़ाइल "C:\ProgramData\Anaconda3\lib\socket.py", लाइन 607, लिखित में
स्व._सॉक.भेजें (बी)
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\greenio\base.py", लाइन 397, भेजने में
स्व._send_loop (self.fd.send, डेटा, झंडे) वापस करें
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\greenio\base.py", लाइन 384, _send_loop में
वापसी send_method (डेटा, * args)
ConnectionAbortedError: [WinError 10053] एक स्थापित कनेक्शन आपके होस्ट मशीन में सॉफ़्टवेयर द्वारा निरस्त कर दिया गया था

उपरोक्त अपवाद को संभालने के दौरान, एक और अपवाद हुआ:

ट्रेसबैक (सबसे हालिया कॉल अंतिम):
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\hubs\hub.py", लाइन 461, fire_timers में
टाइमर ()
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\hubs\timer.py", लाइन 59, __call__ में
सीबी ( तर्क, * किलोवाट)
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\semaphore.py", लाइन 147, _do_acquire में
वेटर.स्विच ()
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\greenthread.py", लाइन 221, मुख्य में
परिणाम = फ़ंक्शन ( तर्क, * kwargs)
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", लाइन 818, process_request में
आद्य.__init__(conn_state, स्वयं)
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", लाइन 359, __init__ में
स्वयं समाप्त ()
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\wsgi.py", लाइन 732, अंत में
बेसएचटीटीपीसर्वर.बेसएचटीटीपीअनुरोधहैंडलर.फिनिश(स्वयं)
फ़ाइल "C:\ProgramData\Anaconda3\lib\socketserver.py", लाइन 784, अंत में
स्वयं.wfile.बंद करें ()
फ़ाइल "C:\ProgramData\Anaconda3\lib\socket.py", लाइन 607, लिखित में
स्व._सॉक.भेजें (बी)
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\greenio\base.py", लाइन 397, भेजने में
स्व._send_loop (self.fd.send, डेटा, झंडे) वापस करें
फ़ाइल "C:\ProgramData\Anaconda3\lib\site-packages\eventlet\greenio\base.py", लाइन 384, _send_loop में
वापसी send_method (डेटा, * args)
ConnectionAbortedError: [WinError 10053] एक स्थापित कनेक्शन आपके होस्ट मशीन में सॉफ़्टवेयर द्वारा निरस्त कर दिया गया था ```

पुष्टि कर सकते हैं कि संतरी पूरी तरह से अक्षम होने पर यह त्रुटि गायब हो जाती है। बहुत अच्छा होगा अगर गनिकोर्न इससे निपटने के लिए पर्याप्त मजबूत हो।

टक्कर @benoitc

पुष्टि कर सकते हैं कि संतरी पूरी तरह से अक्षम होने पर यह त्रुटि गायब हो जाती है। बहुत अच्छा होगा अगर गनिकोर्न इससे निपटने के लिए पर्याप्त मजबूत हो।

मैंने पाया कि संतरी के FlaskIntegration को अक्षम करने से भी त्रुटि गायब हो जाती है।

इसी तरह का व्यवहार देखना। उत्पादन में नए अवशेष का उपयोग फ्लास्क-सॉकेटियो के साथ इस त्रुटि का कारण बनता है। विकास में, कुप्पी-सॉकेटियो शुरू होने से पहले वर्कज़ेग डिबगर मिडलवेयर को लोड करने की आवश्यकता होती है (इसलिए यह इंजिनियो के wsgi ऐप पर लागू नहीं होता है)। समस्या यह है कि उत्पादन वह जगह है जहाँ मैं वास्तव में त्रुटियों को ट्रिपिंग नहीं करना चाहता।

Gunicorn config के post_request में प्रतिक्रिया को प्रतिस्थापित नहीं कर सकता, लेकिन मैंने एक स्थिति कोड को resp.status_code पर ज़बरदस्ती करने का प्रयास किया। हालांकि यह नहीं लिया।

यह त्रुटि Gunicorn और Flask-SocketIO के साथ संतरी के FlaskIntegration का उपयोग करके प्रतिलिपि प्रस्तुत करने योग्य है। क्या जल्द ही इसका समाधान संभव है?

@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

उदाहरण गनिकोर्न कॉन्फ़िगरेशन:

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 "-" "-"

नोट: मैंने वास्तव में स्वयं कभी संतरी का उपयोग नहीं किया है। यह सिर्फ संतरी के आरंभिक पृष्ठ से है। उदाहरण dsn हमारे परीक्षण के लिए ठीक काम करता है।

integrations=[FlaskIntegration()] पर टिप्पणी करने से त्रुटि समाप्त हो जाएगी (बेशक प्रभावी रूप से संतरी को अक्षम करना)।

इसके लायक क्या है, बिना त्रुटियों के इवेंटलेट के बजाय gevent-websocket का उपयोग किया जा सकता है। हालांकि, ऐसा लगता है कि सभी अनुरोधों को संभालना प्रतीत होता है ..

ठीक है, कुछ खेल रहा था। ऐसा लगता है कि संतरी/न्यूरेलिक प्रतिक्रिया लपेटता है। संतरी के बिना, हमें उम्मीद के मुताबिक <eventlet.wsgi._AlreadyHandled object at 0x7fd0f5b1c0d0> मिलता है और गनिकोर्न का EventletWorker.is_already_handled() पुनरावृत्ति को रोक देगा।

हालांकि, संतरी का उपयोग करते समय, यह चेक में विफल होने के बजाय <sentry_sdk.integrations.wsgi._ScopedResponse object at 0x7f30155a5100> जैसा कुछ बन जाता है

इसके बजाय, हम यह देखने के लिए रेस्पिटर को देख सकते हैं कि क्या यह खाली है। कल आगे देखेंगे।

ठीक है, यहाँ वह समाधान है जिसके साथ मैं आया हूँ:

eventlet_fix.py:
नीचे संपादित देखें

और मेरे गनिकोर्न में config.py: worker_class = 'eventlet_fix.EventletWorker ।

मुद्दा यह है कि संतरी/न्यूरेलिक प्रतिक्रियाओं को लपेटता है, इसलिए हम इसे ईवेंटलेट के ALREADY_HANDLED के विरुद्ध आसानी से जांच नहीं सकते हैं। चूंकि पहले से हैंडल किए गए अनुरोध की प्रकृति यह है कि गनिकोर्न के start_response को कॉल नहीं किया जाता है, हम इसके बजाय प्रतिक्रिया स्थिति की उपस्थिति की जांच कर सकते हैं।

इसलिए मैंने प्रतिक्रिया स्थिति की जांच करने के लिए wsgi कॉल को हाईजैक कर लिया है, और आवश्यकतानुसार प्रतिक्रिया मानों को हैक कर लिया है। यह अनुरोध को अभी भी gunicorn द्वारा लॉग इन करने की अनुमति देता है। यदि इसके बजाय, यह मूल व्यवहार को बनाए रखना चाहता है, तो इसके बजाय StopIteration को बढ़ाया जा सकता है।

101 की स्थिति को हैक करना हमारे यहां उपयोग के मामले (फ्लास्क-सॉकेटियो वेबसोकेट) के लिए उपयुक्त है, लेकिन अन्यथा, इसे छोड़कर कोई भी काम नहीं करता है क्योंकि headers_sent और should_close को ट्रू के लिए मजबूर किया जाता है।

फिर, यह धारणा बनाता है कि यदि status सेट नहीं है, तो start_response को कॉल नहीं किया गया था, और इसलिए अनुरोध को बाहरी रूप से "पहले से ही संभाला" जाना चाहिए था।

संपादित करें: अच्छा नहीं। पुनर्मूल्यांकन करना होगा। यदि अनुरोध को निष्पादित करने में समय लगता है, तो $ resp.status start_response को कॉल नहीं किया जाएगा।

संपादित करें 2: हैक किए गए प्रतिक्रिया इटरेटर के साथ एक निश्चित संस्करण यहां दिया गया है:

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 में जा सकता है। कुंजी (अप्रत्यक्ष रूप से) जांच करने के लिए हो सकती है कि start_response को respiter के माध्यम से पुनरावृत्त करने के बाद कॉल किया गया था, या तो resp.status (केवल start_response कहा जाता है) या resp.headers_sent (पुष्टि करें कि हमने वास्तव में अनुरोध का जवाब दिया है)।

@benoitc
@ziddy ने समस्या को हल करने का एक तरीका ढूंढ लिया है।

@ziddy आपके उदाहरण के लिए त्वरित प्रश्न (जैसा कि मैं संतरी का उपयोग नहीं कर रहा हूं)।

• क्या त्रुटि केवल संतरी को प्रभावित कर रही है या अनुरोध भी रोक दिया गया है, यानी कार्यकर्ता समाप्त हो रहा है (जो मुझे संदेह है कि प्रतिक्रिया लपेटी गई है)?
• क्या आप उम्मीद करते हैं कि वहां कुछ लपेटा जाए या अनुरोध को साफ किया जाए, अगर प्रतिक्रिया लपेटी गई है तो ठीक रहेगा?

@benoitc वर्तमान में परीक्षण करने में सक्षम नहीं है, लेकिन https://github.com/benoitc/gunicorn/issues/1852#issuecomment -697189261 और https://github.com/benoitc/gunicorn/blob/4ae2a05c37b332773997f90ba7542713b9bf8274/ Gunicorn/workers/base_async.py#L107 -L140

आम तौर पर, is_already_handled सच लौटेगा और यह यहीं समाप्त होगा।

हालाँकि, क्योंकि प्रतिक्रिया लिपटी हुई है, वह विधि काम नहीं करती है। इसके बजाय, निष्पादन आगे बढ़ता है, पंक्ति 115 पर विफल: resp.close() हेडर भेजने का प्रयास करता है, लेकिन start_response को कभी भी कॉल नहीं किया गया था, इसलिए कोई स्थिति कोड नहीं है। अगर ऐसा किया भी, तो भी यह अंततः स्पष्ट रूप से विफल हो जाएगा।

इसके परिणामस्वरूप एक विशेषता त्रुटि होती है जिसे handle_error द्वारा पुन: व्यवस्थित और माना जाता है। चूंकि अनुरोध पहले ही बाहरी रूप से संभाला जा चुका था, इसलिए लॉग स्पैम के अलावा यहां कोई नुकसान नहीं है।

मैं संतरी के बारे में बहुत कुछ नहीं कह सकता-- मैं इसका उपयोग भी नहीं कर रहा हूँ।

हालांकि एक विवरण: मौजूदा पहले से संचालित तंत्र के परिणामस्वरूप लॉगिंग नहीं होती है। मुझे लगता है कि यह तकनीकी रूप से समझ में आता है क्योंकि यह जानने का कोई तरीका नहीं है कि इसे बाहरी रूप से कैसे संभाला गया। मेरी हैक की गई प्रतिक्रिया में, मैं स्थिति कोड को headers_sent के साथ सत्य के रूप में 101 पर मजबूर करता हूं ताकि हैंडलर आगे बढ़ सके और अनुरोध अभी भी लॉग हो जाए।

resp.status की जाँच यह निर्धारित करने के लिए एक निश्चित परीक्षण है कि start_response को कॉल किया गया था या नहीं।

@benoitc इस पर दोबारा गौर कर रहा है। अधिक निश्चित रूप से निष्कर्ष निकालने के लिए कि अनुरोध पहले ही संभाला जा चुका है, environ['gunicorn.socket'] इसके बजाय अंतर्निहित वस्तु के लिए किसी प्रकार का प्रॉक्सी हो सकता है। इस तरह, इसे रिकॉर्ड किया जा सकता है जब सॉकेट को सीधे एक्सेस किया जाता है (उदाहरण के लिए ईवेंटलेट के लिए get_socket() लपेटना), और is_already_handled जैसी किसी चीज़ के लिए उपयोग किया जाता है

यदि एक्सेस लॉगिंग वांछित है, तो इसे अभी भी प्रतिक्रिया स्थिति को हैक करने की आवश्यकता होगी।