Closed eino closed 2 years ago
This seems to be a good approach especially if you kind of know how to reproduce/test it to validate your patch.
Please go ahead and make a PR. Thanks!
The hardest is indeed to reproduce. So far my efforts have been unsuccessful (but I stumbled on an unrelated issue and opened a PR for it). Will keep you posted.
Finally got my finger on it. If an exception is raised in current_ws.prepare
(and probably could happend also if one is raised in onMessage
, though I couldn't produce it), the client disconnection wasn't registered. Opened a PR for it.
:tada: This issue has been resolved in version 1.8.4 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
Describe the bug
Hi, We have met this issue where in some cases the asyncio server doesn't detect a client has disconnected (probably when they disconnect improperly). This causes the wslink server to never pass through the disconnection code, and thus continue running forever.
To Reproduce
Hard to reproduce systematically. I'm still trying to find a way to product the issue with no doubt, though it's presumably:
Expected behavior / Fix
It's probably linked to issue known in wslink for a couple of years: https://github.com/aio-libs/aiohttp/issues/5301 https://github.com/aio-libs/aiohttp/issues/5212
As the case may be not fixed in aiohttp, it could be handled in wslink.
I'm thinking at the points where wslink is writing to the socket (
ws.send_str
insendWrappedMessage
andsendWrappedError
), catch anyConnectionResetError
, and in this case, close the socket (await self.onClose(client_id)
,del self.connections[client_id]
), and if there are no more clients, schedule shutdown.Do you think it's a good approach? If it looks sound, I can start building up a PR. I'll try to find a reliable way to produce the issue as well.
wslink version: v1.8.2