Candidate fix for #526 (unsupported _context param) #565
Conversation
refresh fork from upstream repository
|
The first step is to verify that we already have at least one test that demonstrates this issue with Python 3.7.3. If not, such a test must be added. That's why the initial commit for this PR is only a comment. |
Codecov Report
@@ Coverage Diff @@
## master #565 +/- ##
======================================
+ Coverage 46% 46% +<1%
======================================
Files 81 81
Lines 7976 7976
Branches 1365 1365
======================================
+ Hits 3723 3725 +2
+ Misses 3997 3995 -2
Partials 256 256
Continue to review full report at Codecov.
|
1 similar comment
Codecov Report
@@ Coverage Diff @@
## master #565 +/- ##
======================================
+ Coverage 46% 46% +<1%
======================================
Files 81 81
Lines 7976 7976
Branches 1365 1365
======================================
+ Hits 3723 3725 +2
+ Misses 3997 3995 -2
Partials 256 256
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #565 +/- ##
=====================================
- Coverage 46% 45% -1%
=====================================
Files 81 81
Lines 7976 8013 +37
Branches 1365 1374 +9
=====================================
- Hits 3722 3681 -41
- Misses 3998 4068 +70
- Partials 256 264 +8
Continue to review full report at Codecov.
|
|
Well. Travis's python37 is 3.7.1, which doesn't drive the problem. |
|
Okay, so I specified Python 3.7.3 for Travis testing -- and all existing tests passed! Yet I can reproduce #526 merely by attempting a simple Means (a) there's some other factor involved than specifically Python 3.7.3 or (b) we don't yet have a test that drives this problem. I'll pursue (b) for now. |
|
Any update on this? python3.7.4 with celery, eventlet and request just fails. |
…tatus. On child-process timeout, instead of merely returning a string containing 'FAIL - timed out', raise AssertionError so the calling test actually fails. Adjust test_run_python_timeout() to expect that AssertionError. Also, even when expect_pass=False, check child-process rc, and raise AssertionError if it's not in the list of allowable values. Add a new keyword parameter 'allow' whose default value is [0]. Modify tests.patcher_test.MonkeyPatch.test_typeerror(), which expects rc 1, to pass allow=[1]. Modify patcher_test.ProcessBase.launch_subprocess() to pass through arbitrary keyword arguments to run_python() to support that.
The new monkey_patch_socket_https_526.py test script depends on an 'openssl' executable in the PATH. Using this, it creates temporary certificate files with which to populate an SSLContext so that a local server can accept HTTPS connections. We run it by tests.openssl_test.test_https() calling run_isolated() to launch a new Python interpreter without eventlet imports. For the same reason, the test script uses multiprocessing to launch the server as a separate process. Only the client code imports eventlet and uses monkey_patch(socket=True), which drives the reported issue.
Print the child process output in addition to reporting its rc. Fix tests.test_run_python_timeout() str/bytes mismatch.
At least not according to pycodestyle.
Also revert specifying exactly Python 3.7.3, which is no longer current.
|
Odd. The new test script is currently failing to import requests -- despite the successful pip install requests earlier in the same run. |
|
Yes: I just clicked through all the reported failures. Same thing: missing |
Not all of our tox environments support the current version of requests.
|
Good news: we finally have a test that drives the problem! |
|
Okay! On this branch we have a single new test that drives the reported problem. |
Remove GreenSSLContext.wrap_socket() override, which blows up with the original TypeError: wrap_socket() got an unexpected keyword argument '_context' exception. Instead, set GreenSSLContext.sslsocket_class to GreenSSLSocket, which obviates the wrap_socket() override. Also, for Python 3.7, remove GreenSSLSocket.__new__() override, which blows up because SSLSocket._create() calls __new__() with (default) socket=None. Python 3.7's SSLSocket._create() does the heavy lifting of instantiating SSLSocket, whose __init__() method unconditionally raises TypeError to discourage hand-constructing SSLSocket. Unfortunately, from SSLSocket's subclass GreenSSLSocket, _create()'s super(SSLSocket, self).__init__(...) call reaches SSLSocket.__init__(), producing that TypeError. Replicate base-class _create() into GreenSSLSocket, except directly call socket.socket.__init__(), which that call is intended to reach.
|
Hi guys. Any updates on this? |
|
Looks like #526 was closed some other way. |
Fixes #526