Tasks stuck in cancelling state – idle_conn_watch_task never finishes under cancellation on Windows

[thomas-xin]

Subject

This is a followup to our conversation at thomas-xin/Miza@d1a9573#r165312062 - While the original bug appears to be fixed, the current state of the library appears to very occasionally cause deadlocks instead.

Environment

OS Windows-11-10.0.26220-SP0
Python 3.13.8
OpenSSL 3.0.18 30 Sep 2025
urllib3 2.14.906

Steps to Reproduce

I believe I can't give exact steps to reproduce, as this is an inconsistent issue that gradually builds up "leaked" stuck tasks as more requests are performed. The only thing that remains consistent is that it occurs with session reuse.
To be clear, I am invoking the request via niquests and not urllib3-future directly, but I have traced the problematic sections to this library, as seen below. Note that due to the nature of this problem, there is no naturally occurring exception or traceback to be shown.

Expected Behavior

Requests should either complete correctly, give a relevant error, or produce a timeout.
Even if timeout does not occur for any reason, it should remain cancellable at any point.

Actual Behavior

The task never finishes despite the request being given a timeout, remaining in pending state.
If wrapped with asyncio.wait_for, after that timeout expires, the task becomes "cancelling" but never exits that state either. This also can occur if the request is cancelled directly with .cancel().

When probing its properties, something similar to the following can be found:
<Task cancelling name='Task-680' coro=<idle_conn_watch_task() running at ...\Python313\site-packages\urllib3\_async\connectionpool.py:171> wait_for=<Future pending cb=[Task.task_wakeup()] created at ...\Python313\Lib\asyncio\base_events.py:459> created at ...\Python313\Lib\asyncio\tasks.py:410>

When issuing traceback.print_stack, I will typically see the following line:
File "...\Python313\site-packages\urllib3\_async\connectionpool.py", line 171, in idle_conn_watch_task await asyncio.sleep(waiting_delay)

And finally, when inspecting the .cancelling() method of the task, I will typically see a very large number in the hundreds, such as 715. This perhaps implies something is swallowing asyncio.CancelledError, however I have not been able to find the cause from the source code itself.
I hope this information is still useful, however!

[Ousret]

We drafted a candidate fix. Could you try and report back?

pip install "git+https://github.com/jawah/urllib3.future.git@release-2.14.907"

regards,

[thomas-xin]

Unfortunately this does not appear to have made any difference.
The task remains stuck, and when inspected is still reporting being on the line with the await.

I should also mention that I attempted to run under the Selector event loop policy as a comparison, but received the following:

...Python313\Lib\selectors.py", line 305, in _select
    r, w, x = select.select(r, w, w, timeout)
              ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
OSError: [WinError 10038] An operation was attempted on something that is not a socket

Though this may be out-of-scope, I thought I'd mention it anyway.

I will keep investigating on my part as well, appreciate the quick response so far!

Regards

[Ousret]

It's harder than I though, Windows have a lot of weird edge cases in asyncio scheduling.
The best course of action I can think of is to have a minimal reproducer, I will try to get my hand on a Windows machine to witness the issue directly. The selector loop bug seems concerning, I will look into that at my earliest.

regards,

[Ousret]

closed by accident via automation. only the "Selector event loop policy" is fixed.

[thomas-xin]

It would appear that neither has been fixed for me?

If you need a copy of what I am using to test, the following two examples cause the same error still (on 2.14.907):

import asyncio
import selectors
import niquests

async def test():
	async with niquests.AsyncSession() as session:
		return await session.get("https://github.com/jawah/urllib3.future/issues/293")

loop = asyncio.SelectorEventLoop(selectors.SelectSelector())
asyncio.set_event_loop(loop)
loop.run_until_complete(test())

import asyncio
import niquests

async def test():
	async with niquests.AsyncSession() as session:
		return await session.get("https://github.com/jawah/urllib3.future/issues/293")

asyncio.set_event_loop_policy(asyncio.WindowsSelectorEventLoopPolicy())
asyncio.run(test())

On the other hand, the following does not cause this immediate OSError (with and without the set_event_loop_policy line, since this is the default behaviour):

import asyncio
import niquests

async def test():
	async with niquests.AsyncSession() as session:
		return await session.get("https://github.com/jawah/urllib3.future/issues/293")

asyncio.set_event_loop_policy(asyncio.WindowsProactorEventLoopPolicy())
asyncio.run(test())

I am mainly reporting this bug as it was interfering with me attempting to test whether the Proactor loop was causing the endless pending/cancelling issue from before.

Regards