Remove workaround for a bug that is long fixed in a EOL python version, that isn't used by us.
If the workaround is still needed, it should at least log the exception before silently discarding it, so that debugging is possible/easier.
Remove workaround for a bug that is long fixed in a EOL python version, that isn't used by us.
If the workaround is still needed, it should at least log the exception before silently discarding it, so that debugging is possible/easier.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | fanquake |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Concept ACK
Also, move the burden of checking for a timeout to the client and
disable the timeout on the server. This should avoid intermittent issues
in slow tests (for example mining_getblocktemplate_longpoll.py, or
feature_dbcrash.py), or possibly when the server is running slow (for
example in valgrind). There shouldn't be any downside in tests caused
by a high rpcservertimeout.
389 | @@ -390,6 +390,8 @@ def write_config(config_path, *, n, chain, extra_config="", disable_autoconnect= 390 | f.write("[{}]\n".format(chain_name_conf_section)) 391 | f.write("port=" + str(p2p_port(n)) + "\n") 392 | f.write("rpcport=" + str(rpc_port(n)) + "\n") 393 | + # Disable server-side timeouts to avoid intermittent issues 394 | + f.write("rpcservertimeout=99000\n")
Can drop -rpcservertimeout=900 from feature_dbcrash given we are setting the default here?
thx, done
This PR seems to remove 2 workarounds: https://bugs.python.org/issue3566 and https://bugs.python.org/issue33450. 3566 is marked as resolved (and indeed for Python 3.5) so I think that can be safely removed. 33450 however is still open and also affects Python 3.6. In the description, I can't find in which macOS version this stopped being an issue. Do you have any sources that confirm we can indeed remove this safely?
however is still open and also affects Python 3.6.
Our minimum required Python is 3.7.
Looks like the new home for this issue is also https://github.com/python/cpython/issues/77631
This patch here disables the server timeout, so there shouldn't be any reason for the socket to be closed while sending on macos. However, if that workaround is still needed, it should be guarded by a macos check. So my suggestion would be to assume the workaround is no longer needed, unless someone can prove otherwise?
ACK fae66fceb3147385320593d1e15faf290b0f4caf
I agree. Not seeing any issues with this on macOS, so lets merge, and revisit if any issues occur.