Crash Report
With -n 2, mypy fails with "Failed to establish connection with worker: No status file found" although both workers started and wrote their status files in time. build() starts the workers and their connect() threads before build_inner() loads plugins. If a plugin import holds the GIL past the 3 s WORKER_START_TIMEOUT, the threads cannot poll, and when they next run the loop has timed out and exits without reading the status file again.
We hit this in PyVista, whose plugin imports VTK, on the first run in a new environment. On macOS the first dlopen() of a newly installed binary waits for an XProtect scan while holding the GIL, so that import blocks for 12 to 17 s (0.12 s afterwards). In one failing run the workers wrote their status files 1.2 s after spawn, and the coordinator was still in the plugin import 12 s later.
Reading the status file once more after the deadline fixes the ctypes reproduction below (tested on master):
--- a/mypy/build.py
+++ b/mypy/build.py
@@ -289,11 +289,13 @@ class WorkerClient:
def connect(self) -> None:
end_time = time.time() + WORKER_START_TIMEOUT
last_exception: Exception | None = None
- while time.time() < end_time:
+ while True:
try:
data = read_status(self.status_file)
except BadStatus as exc:
last_exception = exc
+ if time.time() >= end_time:
+ break
time.sleep(WORKER_START_INTERVAL)
continue
try:It does not reliably fix the VTK case: when the stall outlasts the worker's own 10 s WORKER_CONNECTION_TIMEOUT, the worker has stopped waiting and the run fails with Failed to establish connection with worker: [Errno 2] No such file or directory instead. Starting the workers after plugins are loaded may avoid both. It would also help to report this as an ordinary error rather than an INTERNAL ERROR. #21969 and #21974 look similar but have different causes.
Traceback
error: INTERNAL ERROR -- Please try using mypy master on GitHub:
https://mypy.readthedocs.io/en/stable/common_issues.html#using-a-development-mypy-build
Please report a bug at https://github.com/python/mypy/issues
version: 2.3.1
note: use --pdb to drop into pdb
Failed to establish connection with worker: No status file found
Failed to establish connection with worker: No status file found
Traceback (most recent call last):
File ".../venv/lib/python3.14/site-packages/mypy/__main__.py", line 16, in console_entry
main()
~~~~^^
File "mypy/main.py", line 154, in main
File "mypy/main.py", line 244, in run_build
File "mypy/build.py", line 422, in build
File "mypy/build.py", line 537, in build_inner
File "mypy/build.py", line 4145, in dispatch
OSError: Cannot connect to build worker(s): 0, 1To Reproduce
A plugin that holds the GIL for 4 s. This fails on every run, with 2.3.1 and with master; sleep(2) passes.
mkdir pkg && echo 'x: int = 1' > pkg/__init__.py
cat > gil_plugin.py <<'EOF'
import ctypes
from mypy.plugin import Plugin
# Hold the GIL for 4 s, as a slow import of a compiled extension can.
ctypes.PyDLL(None).sleep(4)
def plugin(version: str) -> type[Plugin]:
return Plugin
EOF
printf '[mypy]\nplugins = gil_plugin.py\n' > mypy.ini
mypy -n 2 --show-traceback pkgOn macOS, import vtkmodules.vtkRenderingCore in place of the ctypes lines, in a new venv with mypy==2.3.1 vtk==9.7.0, fails on the first run and passes on the second. Precompiling bytecode (UV_COMPILE_BYTECODE=1) makes no difference.
Your Environment
- Mypy version used: 2.3.1 (compiled: yes), and master at b645e06 (from git, not compiled)
- Mypy command-line flags:
-n 2 --show-traceback
- Mypy configuration options from
mypy.ini (and other config files): plugins = gil_plugin.py
- Python version used: 3.14.0 and 3.14.5
- Operating system and version: macOS 26.6.2, arm64 (the
ctypes reproduction should not be macOS-specific, but I only ran it there)
Investigated and drafted with Claude Code (Claude Opus 5.5).
Crash Report
With
-n 2, mypy fails with "Failed to establish connection with worker: No status file found" although both workers started and wrote their status files in time.build()starts the workers and theirconnect()threads beforebuild_inner()loads plugins. If a plugin import holds the GIL past the 3 sWORKER_START_TIMEOUT, the threads cannot poll, and when they next run the loop has timed out and exits without reading the status file again.We hit this in PyVista, whose plugin imports VTK, on the first run in a new environment. On macOS the first
dlopen()of a newly installed binary waits for an XProtect scan while holding the GIL, so that import blocks for 12 to 17 s (0.12 s afterwards). In one failing run the workers wrote their status files 1.2 s after spawn, and the coordinator was still in the plugin import 12 s later.Reading the status file once more after the deadline fixes the
ctypesreproduction below (tested on master):It does not reliably fix the VTK case: when the stall outlasts the worker's own 10 s
WORKER_CONNECTION_TIMEOUT, the worker has stopped waiting and the run fails withFailed to establish connection with worker: [Errno 2] No such file or directoryinstead. Starting the workers after plugins are loaded may avoid both. It would also help to report this as an ordinary error rather than an INTERNAL ERROR. #21969 and #21974 look similar but have different causes.Traceback
To Reproduce
A plugin that holds the GIL for 4 s. This fails on every run, with 2.3.1 and with master;
sleep(2)passes.On macOS,
import vtkmodules.vtkRenderingCorein place of thectypeslines, in a new venv withmypy==2.3.1 vtk==9.7.0, fails on the first run and passes on the second. Precompiling bytecode (UV_COMPILE_BYTECODE=1) makes no difference.Your Environment
-n 2 --show-tracebackmypy.ini(and other config files):plugins = gil_plugin.pyctypesreproduction should not be macOS-specific, but I only ran it there)Investigated and drafted with Claude Code (Claude Opus 5.5).