While running tests on riscv64, I'm seeing consistent test failures:
FAILED tests/test_uds.py::test_asgi[mt] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_asgi[st] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_rsgi[mt] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_rsgi[st] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_wsgi[mt] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_wsgi[st] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_https[mt-asgi] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_https[mt-rsgi] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_https[mt-wsgi] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_https[st-asgi] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_https[st-rsgi] - httpx.ConnectError: [Errno 111] Connection refused
FAILED tests/test_uds.py::test_https[st-wsgi] - httpx.ConnectError: [Errno 111] Connection refused
Full build + test log here: https://gist.github.com/WhyNotHugo/8b5badba18a3895a5c21acb926d49e4c#file-job-log
Hypothesis
I don't think that the root of the issue is the architecture itself: I think the tests themselves are racey, and because our riscv64 builders are slower hardware, the races trigger consistently.
test_uds.py creates a socket and waits a fixed 1.5s before yielding. The socket is first bound and then listened, but these test failures reflect that they're bound but the listener isn't up yet. Sleeping like this doesn't ensure that the service is ready.
Potential fixes
The ideal fix here is to wait for readiness, so that fast environments don't need to wait 1.5s, and slow environment wait as much as necessary.
It's also more common to call listen() and then bind(), so that the socket only exists if some process is listening on it. If this approach were taken, tests would have a fast loop sleeping 10ms, checking socket existence, and then
While running tests on riscv64, I'm seeing consistent test failures:
Full build + test log here: https://gist.github.com/WhyNotHugo/8b5badba18a3895a5c21acb926d49e4c#file-job-log
Hypothesis
I don't think that the root of the issue is the architecture itself: I think the tests themselves are racey, and because our riscv64 builders are slower hardware, the races trigger consistently.
test_uds.pycreates a socket and waits a fixed1.5sbefore yielding. The socket is first bound and then listened, but these test failures reflect that they're bound but the listener isn't up yet. Sleeping like this doesn't ensure that the service is ready.Potential fixes
The ideal fix here is to wait for readiness, so that fast environments don't need to wait 1.5s, and slow environment wait as much as necessary.
It's also more common to call
listen()and thenbind(), so that the socket only exists if some process is listening on it. If this approach were taken, tests would have a fast loop sleeping 10ms, checking socket existence, and then