GeezerVison

@1st1 Please have a look! thx

@fantix could you review? this seems like a critical issue under high concurrency

Hey @junjzhang @6matt, perhaps one option for you would be to switch to aiofastnet? Not only it is faster, its networking source code is following python 3.14 asyncio implementation, which doesn't have this bug.

And if there is any other bug, I can fix it and release much faster.

I waited for more than a year to get some of my uvloop PRs merged, and they haven't been released yet.

Just saying

I think this is a duplicate of #646

I think this is a duplicate of #646

Good call! Though, #646 fixed it in a way that breaks asyncio compatibility. I think this PR is a better approach. Let me also add a theoretical test to reproduce #645, as well as aio-libs/aiohttp#10506.

I think this is a duplicate of #646

Good call! Though, #646 fixed it in a way that breaks asyncio compatibility. I think this PR is a better approach.

Thanks for the background. I think the #646 approach was to make passed in socket (PSO) handling more like internally generated socket handling. When libuv generates the socket (such as through an accept call), there is no PSO so uvloop creates an internal wrapper. As a result, there are code paths that have to distinguish between a PSO and an internally-wrapped socket. The #646 change made everything just an internally wrapped socket.

Yeah, what you said is indeed an ideal resolution, but it is no longer identical to asyncio - where the passed-in sock object is still accessible by the caller, no matter how much it is suggested not to be messed with. The referenced asyncio PR was to forbid such wrong usages by re-wrapping the given sock object, but that PR was never landed in upstream, that's why uvloop had all those transport._attach_sockobj() workarounds for years.

Hey first of all thanks for the fix @junjzhang
Can we get an approximate timeline @fantix when this will be released?
Thanks

We hit what appears to be the same failure mode in a production disaggregated inference service using Python 3.12, uvloop 0.22.1, aiohttp 3.14.1, and Uvicorn.

Under concurrent aiohttp connection attempts, retries, and cancellation, the API process first returned readiness, then its connections were reset, and the process terminated natively with SIGABRT (Aborted (core dumped)). The timing and descriptor-reuse behavior are consistent with the stale Python socket object closing an fd already closed by libuv and later recycled into another transport. The resulting outage produced thousands of downstream 503 responses.

We have switched the affected proxy and Python API serving paths to the standard-library asyncio loop in our release candidate. We plan to keep uvloop disabled until a release containing dc680eb20c526d8babacaf4751a12f51431ea246 is available and passes our cancellation stress and production-shaped load checks.

Thank you for fixing this and for adding the TCP and Unix socket regression coverage. An approximate release timeline would be very helpful for downstream users deciding when it is safe to re-enable uvloop.