anyio
anyio copied to clipboard
agronholm
Fix memory streams incorrectly raising cancelled when `*_nowait()` is called immediately after cancelling `send()`/`receive()`
Changes
Fixes:
-
#728 (in sense (1) as defined in https://github.com/agronholm/anyio/issues/728#issuecomment-2105664591). cancellation of
receive()could drop items, meaning that neither the attempted sender nor the attempted receiver think they are responsible for the item. -
the analogous issue about cancellation of
send(). cancellation ofsend()could result insend()raising cancelled despite succeeding, meaning that both the attempted sender and the attempted receiver think they are responsible for the item.
Checklist
If this is a user-facing code change, like a bugfix or a new feature, please ensure that the you've fulfilled the following conditions (where applicable):
- [x] You've added tests (in
tests/) added which would fail without your patch - [ ] You've updated the documentation (in
docs/, in case of behavior changes or new features) - [x] You've added a new changelog entry (in
docs/versionhistory.rst).
If this is a trivial change, like a typo fix or a code reformatting, then you can ignore these instructions.
This was the first solution that came to my mind, but then I realized it would interact poorly with asyncio's native cancellation.
This was the first solution that came to my mind, but then I realized it would interact poorly with asyncio's native cancellation.
could you elaborate on this? i do see now that the branch of receive() that was added in a3af1da23c15af016af2656ebae79bd1580cbee3 (which predates Python 3.11) should probably make an uncancel() call on asyncio >= 3.11, in order to support native cancellations. is this what you mean?
(i just updated this branch to also test for and fix the analogous bug that can occur when send() is cancelled.)
Closing in favor of #735, as I've come to the conclusion that avoiding the item delivery to a task with a pending cancellation is the only viable solution.