Aymeric Augustin
Aymeric Augustin
There a small chance that this is a different symptom of #1555, although I don't have a full theory supporting that.
Protocol state is checked at a lower level, in the Sans-I/O layer, specifically here: https://github.com/python-websockets/websockets/blob/fc7cafea01ebe3ec1738160ac62889fd80653255/src/websockets/protocol.py#L315-L316
Once this is fixed, many cases in section 6 in the Autobahn test suite should result in code 1002 rather than 1000.
Aligning the behavior of the threading implementation to the asyncio implementation (which I wanted to do anyway) will make it easier to get this right for both implementations.
Yes - although I'd need to redo the work to tell if everything is correct - it's faster to redo than to review :-/ e.g. this requires reading the changelog...
I'm quite thorough with these things because I don't like dead code :-)
I'm facing an issue that results in similar symptoms with the test suite of websockets: coverage report neither jumping to the next line, nor exiting. Failed test run: https://github.com/python-websockets/websockets/actions/runs/18993596506/job/54250198634 This...
Thank you for the PR, it's a good starting point. The code requires a few changes (e.g. `async for` vs. `for`). I'll adjust it to make it work then merge.
I intended to do it but didn't work on this projects for a few weeks :-|
Running a second asyncio event loop in a separate thread sounds very sketchy. Indeed, asyncio is not thread-safe. I suspect unsafe calls between the two threads. If you want two...