A few days ago we started investigating failures in the Ranch CI on Windows. They occur when the ssl application is being used. The failures started with OTP-21.2 and can be seen on OTP-21.3 and OTP-22.0 (we later patched to OTP-22.0.1 with the failures still occurring). Since OTP-21.2 introduced the internal active,N this seemed like a good candidate for being the culprit.
Disabling via internal_active_n=1 environment configuration made the tests pass. (It seems ssl does not really disable it as an ssl_passive message is sent every time, but close enough.)
I then extracted the attached module showing the issue. On my Windows environment the test finishes with small ActiveN values, but not with larger ActiveN (as small as 10). No problem using ActiveN=1000 on Arch Linux. It seems that if the port is not queried then it gets stuck or something? It might be worse on OTP-22.0 than previous versions as well based on casual observation. It doesn't seem to be a problem for small payloads / short connections.
I expect it to at least finish, and to finish in a reasonable time. In the Ranch CI we see the relevant ssl tests being more than 10 times slower than they were in OTP-21.1.
It's on a Windows 10 running in VirtualBox on a Windows 10 host. Both should be more or less up to date with Windows patches.