-
Notifications
You must be signed in to change notification settings - Fork 121
port communication over a multiprocessing queue in fixtures #2969
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
matrss
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that the macOS tests still aren't fully reliable with these changes and they definitely introduce a race condition I am sceptical.
tests/fixtures.py
Outdated
| def _reserve_port(host): | ||
| """Only reserve the port for the server""" | ||
| s = socket.socket() | ||
| s.bind((host, 0)) | ||
| port = s.getsockname()[1] | ||
| s.close() | ||
| return port |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did your LLM mention that this port selection mechanism contains a race condition? ;)
Once the socket is .close()'d the OS is free to assign the port to any other process, so it could theoretically happen that a different process starts listening on the port in between the call to _reserve_port and the eventlet.listen later on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes I know this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function has been removed. I discovered that the port can be exchanged using a port queue, allowing us to retain eventlet.listen and use the port directly within the WSGI server. This also resolves the errors I was encountering.
|
Have you tried running the test suite in a loop on your mac? How high is the failure rate there? Or does it really run without errors for hours? Something like a |
will do, this makes the mac a heating system... |
I think we have to look on that tests afterwards. There are already some PR open where we don't wait until qt is finished. We likly have also some timeout problems for wms related tests. |
|
We’re still sometimes experiencing hanging tests that pytest can’t kill, even with this change. But it does enable me to run all tests on my Mac. I also observe these hangs locally; aborting them reveals which tests are affected. This PR doesn't resolve all issues, and I haven’t encountered the errors reported in the issue. Tests running for over 2 minutes were mostly not automatically finished by pytest; I had to manually kill them with Ctrl+C. If there is no [gw*] prefix, it indicates a test that has hung; all others have failed normally. This information wasn’t easily accessible before. For my Mac-based development, this is a big step forward, and I don't believe it will regress the Ubuntu test results. Based on that, I think we should merge. |
removed the race condition |
matrss
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like CI passes more or less 50% of the time now, which is a major improvement for macOS runners. I still don't understand why, but whatever, the changes look fine. Thank you!
Purpose of PR?:
Fixes #2967
That change enables that I can run all tests locally on my macOS.
576 passed, 16 skipped, 92 warnings in 101.63s (0:01:41)The hint to use socket for reserving the port stem from AI-Assistant supporting GPT-5.1-codex-max.
Now that the test code runs fully on my MacBook, I’ve been able to do some more testing to look for problems we see on GitHub. We should postpone investigating other issues like transitioning to
spawnor refining timeout settings.