concurrent anyio.aclose_forcefully fails to block until socket is closed on asyncio

[graingert]

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

f982b24

Python version

3.12

What happened?

Running the following tests fail on asyncio

From 267d773d30a63b9a22b6c389d7c099616e116628 Mon Sep 17 00:00:00 2001
From: Thomas Grainger <tagrain@gmail.com>
Date: Wed, 12 Aug 2026 21:30:48 +0100
Subject: [PATCH] add
 test_concurrent_aclose_forcefully_returns_before_socket_closes

---
 tests/test_sockets.py | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/tests/test_sockets.py b/tests/test_sockets.py
index f475676..b1213ee 100644
--- a/tests/test_sockets.py
+++ b/tests/test_sockets.py
@@ -43,6 +43,7 @@ from anyio import (
     TCPConnectable,
     TypedAttributeLookupError,
     UNIXConnectable,
+    aclose_forcefully,
     as_connectable,
     connect_tcp,
     connect_unix,
@@ -507,6 +508,23 @@ class TestTCPStream:
                 with pytest.raises(ClosedResourceError):
                     await stream.receive()
 
+    async def test_concurrent_aclose_forcefully_returns_before_socket_closes(
+        self, server_addr: tuple[str, int]
+    ) -> None:
+        stream = await connect_tcp(*server_addr)
+        raw_socket = stream.extra(SocketAttribute.raw_socket)
+        fds: list[int] = []
+
+        async def do_aclose() -> None:
+            await aclose_forcefully(stream)
+            fds.append(raw_socket.fileno())
+
+        async with create_task_group() as tg:
+            tg.start_soon(do_aclose)
+            tg.start_soon(do_aclose)
+
+        assert fds == [-1, -1]
+
     async def test_receive_after_close(self, server_addr: tuple[str, int]) -> None:
         stream = await connect_tcp(*server_addr)
         await stream.aclose()
-- 
2.43.0

gets

FAILED tests/test_sockets.py::TestTCPStream::test_concurrent_aclose_forcefully_returns_before_socket_closes[asyncio-ipv4] - assert [15, -1] == [-1, -1]
FAILED tests/test_sockets.py::TestTCPStream::test_concurrent_aclose_forcefully_returns_before_socket_closes[asyncio-ipv6] - assert [15, -1] == [-1, -1]
FAILED tests/test_sockets.py::TestTCPStream::test_concurrent_aclose_forcefully_returns_before_socket_closes[asyncio+uvloop-ipv4] - assert [23, -1] == [-1, -1]
FAILED tests/test_sockets.py::TestTCPStream::test_concurrent_aclose_forcefully_returns_before_socket_closes[asyncio+uvloop-ipv6] - assert [23, -1] == [-1, -1]
FAILED tests/test_sockets.py::TestTCPStream::test_concurrent_aclose_forcefully_returns_before_socket_closes[asyncio+eager-ipv4] - assert [17, -1] == [-1, -1]
FAILED tests/test_sockets.py::TestTCPStream::test_concurrent_aclose_forcefully_returns_before_socket_closes[asyncio+eager-ipv6] - assert [17, -1] == [-1, -1]

How can we reproduce the bug?

see above

[agronholm]

The trivial fix would be to move self._transport.abort() into a finally: block, right?

[graingert]

We also need a cancel shielded checkpoint

[agronholm]

We also need a cancel shielded checkpoint

Do we? Why?

[graingert]

I think abort doesn't actually call socket.close, it schedules it to be called on the next turn of the event loop

[graingert]

Transport.close and Transport.abort are idempotent so we can probably just get rid of the Transport.is_closing() check

[agronholm]

I think abort doesn't actually call socket.close, it schedules it to be called on the next turn of the event loop

That's not the docs imply.

[agronholm]

You may be confusing this with .close() which does work like that, hence the sleep(0) in our code.

[agronholm]

Assuming I'm right, the finally: block would just force-close the connection without waiting for pending data to be sent – exactly what we'd expect when using aclose_forcefully().

[graingert]

Here's the code

https://github.com/python/cpython/blob/main/Lib/asyncio/selector_events.py#L910

[agronholm]

I see. You were right, then, so we need that cancel shielded checkpoint.

[agronholm]

Would you mind creating a PR?

[graingert]

I think it should be folded into #1246

Also I'm not sure why I can't repeat the failure with UDP, but it might be Windows only

[agronholm]

I think that one is fixing a different, albeit related issue.