bug: Error when trying to load an inventory file from an https source #796
Description
Description of the bug
I have a documentation project with mkdocs.yml that contains:
plugins:
- mkdocstrings:
handlers:
python:
inventories:
- https://docs.python.org/3/objects.inv
calling, mkdocs build --verbose, I see:
ERROR - mkdocstrings: Couldn't load inventory https://docs.python.org/3/objects.inv through handler 'python': unknown error (_ssl.c:3103)
To Reproduce
Inspecting mkdocstrings and associated sources, I came up with an MRE decoupled from mkdocstrings:
mre.py
import urllib.request
from concurrent import futures
url = "https://docs.python.org/3/objects.inv"
def download() -> bytes:
req = urllib.request.Request(url)
with urllib.request.urlopen(req) as resp:
return resp.read()
# If uncommented, no failure.
# download()
# This fails
thread_pool = futures.ThreadPoolExecutor()
future = thread_pool.submit(download)
futures.wait([future], timeout=10)
print(future.result())To reproduce,
- Save the above in a file called
mre.py - Run
uvx --python 3.10.18 python mre.py - This produces a traceback that contains "unknown error (_ssl.c:3103)"
Interestingly, if download is called once outside before the threadpool execution, there is no failure.
Another remark is that, the issue is there with 3.11, 3.12, but not with 3.13.
Full traceback
Full traceback
Traceback (most recent call last):
File "/tmp/mre.py", line 20, in <module>
print(future.result())
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/concurrent/futures/_base.py", line 451, in result
return self.__get_result()
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/concurrent/futures/_base.py", line 403, in __get_result
raise self._exception
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/concurrent/futures/thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "/tmp/mre.py", line 9, in download
with urllib.request.urlopen(req) as resp:
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/urllib/request.py", line 216, in urlopen
return opener.open(url, data, timeout)
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/urllib/request.py", line 519, in open
response = self._open(req, data)
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/urllib/request.py", line 536, in _open
result = self._call_chain(self.handle_open, protocol, protocol +
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/urllib/request.py", line 496, in _call_chain
result = func(*args)
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/urllib/request.py", line 1391, in https_open
return self.do_open(http.client.HTTPSConnection, req,
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/urllib/request.py", line 1317, in do_open
h = http_class(host, timeout=req.timeout, **http_conn_args)
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/http/client.py", line 1422, in __init__
context = ssl._create_default_https_context()
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/ssl.py", line 757, in create_default_context
context = SSLContext(PROTOCOL_TLS_CLIENT)
File "/home/ckutlu/.local/share/uv/python/cpython-3.10.18-linux-x86_64-gnu/lib/python3.10/ssl.py", line 496, in __new__
self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: unknown error (_ssl.c:3103)Expected behavior
I would expect to be able to use https sources for inventories
Environment information
python -m mkdocstrings._internal.debug # | xclip -selection clipboard
- __System__: Linux-6.15.4-200.fc42.x86_64-x86_64-with-glibc2.41
- __Python__: cpython 3.10.18 (/home/ckutlu/xyz/.venv/bin/python)
- __Environment variables__:
- __Installed packages__:
- `mkdocstrings` v0.30.0I'm on Fedora 42, usin uv to manage my environment.
Additional context
Suspecting the issue to be unrelated to mkdocstrings, I searched around and found astral-sh/uv#15327 which could be related. It looks like the issue related to the use of urllib together with concurrent.futures.ThreadPoolExecutor, and its somehow platform dependent.