AnyIOStream.write leaks EndOfStream

[Miksus]

Hi!

I'm facing an issue of anyio.EndOfStream exception slips through the exception map in AnyIOStream.write in httpcore/_backends/anyio.py. Based on this issue #808, it seems the read method was fixed from the same error by adding EndOfStream to the exception map in the read. Perhaps the write method could be fixed the same way by modifying this map?

I'm not 100% sure if this is a httpcore issue or bug in the other dependencies though as I'm not too familiar with the topic. I use httpx-ws which uses httpcore underneath. httpx-ws would catch this if it was WriteError and not EndOfStream error so if the EndOfStream error was added to the exception map in httpcore I wouldn't get this issue. My guess is that this is casued by pinging, perhaps the ping writes to a closed stream or the ping closes the stream?

Here is the traceback for the httpcore part:

  | Traceback (most recent call last):
  |   File "/app/.venv/lib/python3.13/site-packages/httpx_ws/_api.py", line 1031, in _background_receive
  |     await self.close(CloseReason.INTERNAL_ERROR, "Stream error")
  |   File "/app/.venv/lib/python3.13/site-packages/httpx_ws/_api.py", line 975, in close
  |     await self.stream.write(data)
  |   File "/app/.venv/lib/python3.13/site-packages/httpcore/_async/http11.py", line 365, in write
  |     await self._stream.write(buffer, timeout)
  |   File "/app/.venv/lib/python3.13/site-packages/httpcore/_backends/anyio.py", line 50, in write
  |     await self._stream.send(item=buffer)
  |   File "/app/.venv/lib/python3.13/site-packages/anyio/streams/tls.py", line 244, in send
  |     await self._call_sslobject_method(self._ssl_object.write, item)
  |   File "/app/.venv/lib/python3.13/site-packages/anyio/streams/tls.py", line 204, in _call_sslobject_method
  |     raise EndOfStream from None
  | anyio.EndOfStream

In case it is relevant, here is what I did with httpx-ws:

from httpx_ws import aconnect_ws

async with aconnect_ws(
    "http://example.com",
    keepalive_ping_interval_seconds=20,
    keepalive_ping_timeout_seconds=20
) as ws:

The full traceback (this is in TaskGroup):

|   File "../myfile.py", line 10, in myfunction
|     async with aconnect_ws(
|                ~~~~~~~~~~~^
|         url,
|         ^^^^
|     ...<2 lines>...
|         keepalive_ping_timeout_seconds=20
|         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|     ) as ws:
|     ^
|   File "/usr/local/lib/python3.13/contextlib.py", line 235, in __aexit__
|     await self.gen.athrow(value)
|   File "/app/.venv/lib/python3.13/site-packages/httpx_ws/_api.py", line 1486, in aconnect_ws
|     async with ws_client.connect(
|                ~~~~~~~~~~~~~~~~~^
|         url, subprotocols=subprotocols, **kwargs
|         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|     ) as websocket:
|     ^
|   File "/usr/local/lib/python3.13/contextlib.py", line 235, in __aexit__
|     await self.gen.athrow(value)
|   File "/app/.venv/lib/python3.13/site-packages/httpx_ws/_api.py", line 1385, in connect
|     async with session:
|                ^^^^^^^
|   File "/app/.venv/lib/python3.13/site-packages/httpx_ws/_api.py", line 650, in __aexit__
|     await self._exit_stack.aclose()
|   File "/usr/local/lib/python3.13/contextlib.py", line 705, in aclose
|     await self.__aexit__(None, None, None)
|   File "/usr/local/lib/python3.13/contextlib.py", line 768, in __aexit__
|     raise exc
|   File "/usr/local/lib/python3.13/contextlib.py", line 751, in __aexit__
|     cb_suppress = await cb(*exc_details)
|                   ^^^^^^^^^^^^^^^^^^^^^^
|   File "/app/.venv/lib/python3.13/site-packages/anyio/_backends/_asyncio.py", line 781, in __aexit__
|     raise BaseExceptionGroup(
|         "unhandled errors in a TaskGroup", self._exceptions
|     ) from None
| ExceptionGroup: unhandled errors in a TaskGroup (1 sub-exception)
+-+---------------- 1 ----------------
  | Traceback (most recent call last):
  |   File "/app/.venv/lib/python3.13/site-packages/httpx_ws/_api.py", line 1031, in _background_receive
  |     await self.close(CloseReason.INTERNAL_ERROR, "Stream error")
  |   File "/app/.venv/lib/python3.13/site-packages/httpx_ws/_api.py", line 975, in close
  |     await self.stream.write(data)
  |   File "/app/.venv/lib/python3.13/site-packages/httpcore/_async/http11.py", line 365, in write
  |     await self._stream.write(buffer, timeout)
  |   File "/app/.venv/lib/python3.13/site-packages/httpcore/_backends/anyio.py", line 50, in write
  |     await self._stream.send(item=buffer)
  |   File "/app/.venv/lib/python3.13/site-packages/anyio/streams/tls.py", line 244, in send
  |     await self._call_sslobject_method(self._ssl_object.write, item)
  |   File "/app/.venv/lib/python3.13/site-packages/anyio/streams/tls.py", line 204, in _call_sslobject_method
  |     raise EndOfStream from None
  | anyio.EndOfStream
  +------------------------------------

Feel free to point to httpx-ws in case this does not seem to be httpcore issue.

[TayfurYldz]

This looks like an httpcore backend-normalization gap rather than something httpx-ws should have to special-case.

The current AnyIO backend already treats EndOfStream as a transport-level condition on reads:

exc_map = {
    TimeoutError: ReadTimeout,
    anyio.BrokenResourceError: ReadError,
    anyio.ClosedResourceError: ReadError,
    anyio.EndOfStream: ReadError,
}

but the corresponding write() map only contains BrokenResourceError and ClosedResourceError. Your traceback shows that this is not theoretical: TLSStream.send() can surface anyio.EndOfStream while trying to write, so it crosses httpcore's backend abstraction unchanged.

That is inconsistent with the purpose of the network backend: callers of httpcore should see httpcore's WriteError, not an AnyIO-specific exception depending on which exact failure path the underlying stream took.

So the minimal fix I would expect is to map:

anyio.EndOfStream: WriteError,

in AnyIOStream.write(), alongside the two existing write-side resource errors, with a regression test where the wrapped stream raises EndOfStream from send() and the public result is httpcore.WriteError.

I would not move this handling into httpx-ws: that would leak knowledge of httpcore's selected backend into a caller and would still leave other httpcore users exposed to the same backend-specific exception.