ClosedResourceError
vs. BrokenResourceError
is sometimes backend-dependent, and is sometimes not raised at all (in favor of a non-AnyIO exception type)
#671
Labels
bug
Something isn't working
Things to check first
I have searched the existing issues and didn't find my bug already reported there
I have checked that my bug is still present in the latest release
AnyIO version
main
Python version
CPython 3.12.1
What happened?
see the title. here are some reproducers for some issues that i noticed while working on a fix for #669: c6f0334...b6576ae
the main question that these tests raise is: if a send stream is in a
Broken
state (i.e. our side of the connection learned that it was closed by the peer, or otherwise broken due to something external) and then is explicitlyaclose()
d by our side, should subsequent calls raiseBrokenResourceError
or should they raiseClosedResourceError
? i.e. if youaclose()
aBroken
send stream, does that "clear" itsBroken
ness and convert it to just beingClosed
?the documentation does not seem to discuss what should happen if the conditions for
ClosedResourceError
andBrokenResourceError
are both met. i am not sure what the behavior here is intended to be (or if it's intended to be undefined behavior?), as currently different streams do different things in this situation, with the behavior sometimes also varying between backends.my initial intuition was that the intended behavior was to give precedence to
raise BrokenResourceError
overraise ClosedResourceError
(this choice prevents the stream from changing fromBroken
toClosed
). I thought this becuase this behavior looks like it was rather explicitly chosen when implementing the "important" asyncio-backend streams (TCP and UDP): they explicitly do not setself._closed
if they are already closing due to an external cause:SocketStream
anyio/src/anyio/_backends/_asyncio.py
Lines 1173 to 1184 in c6efbe3
UDPStream
anyio/src/anyio/_backends/_asyncio.py
Lines 1459 to 1463 in c6efbe3
so I started to implement it: here is most of an implementation of that behavior: c6f0334...1be403d 1
however,
MemoryObjectSendStream
is also an "important" stream and it has the opposite behavior, even on the asyncio backend.How can we reproduce the bug?
see above
Footnotes
note: github shows these commits out of order as it's sorting based on time rather than doing a correct topological sort, so it may be easier to look at these locally, in order. ↩
The text was updated successfully, but these errors were encountered: