You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit bf24d14
Browse filesBrowse the repository at this point in the historyBrowse files
fix: every surface raises the error that says what happened
The split into ChannelClosed, GatewayGone and ExecnetStateError reached
only the sync channel. The async core behind execnet.trio, execnet.aio
and execnet.raw_trio still raised a bare OSError for the same events, so
the names those namespaces export were never raised there.
Connection gone: sends on a closed channel are ChannelClosed, sends and
opens on a finished connection GatewayGone, and a write that times out is
execnet.TimeoutError. The reader and writer store a lost connection as
GatewayGone, which is what receive raises on every surface. They also
stored the backend's own ClosedResource/BrokenResource before, which
receive then raised as-is; it is kept only as the cause now.
Misuse: a group used before start or started twice, blocking inside a
running event loop or on the engine's own loop thread, and using a closed
engine raise ExecnetStateError instead of plain RuntimeError, which it
subclasses. Registering a second callback moves from OSError to
ExecnetStateError, the same break as the two channel misuse cases.
Environment and internal-invariant errors stay RuntimeError: a missing
uv, a monkey-patched process, an engine that cannot start. So does the
deprecated RSync adapter's OSError, which keeps its 2.x behaviour.
Five of the six new tests fail against the previous code; the sixth
(sync send after close) was already ChannelClosed.
Co-Authored-By: Claude Opus 5.5 (1M context) via Claude Code <noreply@anthropic.com>
0 commit comments