Codecov Report

❌ Patch coverage is 77.77778% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 87%. Comparing base (19912d0) to head (4927768).
⚠️ Report is 1 commits behind head on master.

@@           Coverage Diff           @@
##           master   #21335   +/-   ##
=======================================
- Coverage      87%      87%   -0%     
=======================================
  Files         270      269    -1     
  Lines       23799    23708   -91     
=======================================
- Hits        20629    20536   -93     
- Misses       3170     3172    +2     

If I understand the fix correctly, we are now rely on the test creator to explicitly set the STANDALONE_PORT env variable to avoid the port conflict? How can it prevent the port conflict if multiple test with the same range got launched at the same time and run into conflict ? Maybe I missed something? @deependujha

Hi @littlebullGit,

We aren't using pytest-xdist to launch tests in parallel, but rather standalone shell script.

standalone shell script doesn't launches tests at once, but, it does it one by one, stores PID, and then keeps checking if they passed, and then launches next batch of tests.

pytest tests/.../test_file.py::test_name

Since the shell script itself is a single process, it can reliably use a list to store used ports and assign new for next test launch.

Hence, we can reliably say that multiple tests won't be launched with the same port.

Hi @littlebullGit,

We aren't using pytest-xdist to launch tests in parallel, but rather standalone shell script.

standalone shell script doesn't launches tests at once, but, it does it one by one, stores PID, and then keeps checking if they passed, and then launches next batch of tests.

pytest tests/.../test_file.py::test_name

Since the shell script itself is a single process, it can reliably use a list to store used ports and assign new for next test launch.

Hence, we can reliably say that multiple tests won't be launched with the same port.

Now it makes sense. Since the shell is guarantee to be the only process on the server which issue ports, it effectively does the same as the file lock approach I did for the port manager.

yeah, and it was really cool.

The only issue with it was, this was not a user-facing bug, but a simple test launching issue, and shell script specifying port is a decent fix imo.

Thanks again for your time and great effort.