Hm, that's interesting. So we should not conflate the port that is passed via the capabilities and the actual port used in those tests. The port `59211` above is the one set by wptrunner and which is used for the normal wdspec tests. But for the Mozilla specific classic tests we use the `geckodriver` fixture and that gets its own port by calling the `get_free_port` helper. But there is one interesting case. The port `37438` where we fail to get geckodriver started is here: https://treeherder.mozilla.org/logviewer?job_id=420098181&repo=mozilla-central&lineNumber=266928-266932 ``` [task 2023-06-21T04:57:33.885Z] 04:57:33 INFO - STDOUT: Running command: /builds/worker/fetches/geckodriver --port 37438 -vv --binary /builds/worker/workspace/build/application/firefox/firefox --allow-origins http://web-platform.test:8000 [task 2023-06-21T04:57:33.890Z] 04:57:33 INFO - Test harness output was not a valid structured log message [task 2023-06-21T04:57:33.890Z] 04:57:33 INFO - /builds/worker/fetches/geckodriver: error: Address in use (os error 98) [task 2023-06-21T04:57:33.890Z] 04:57:33 INFO - WebDriver implementation for Firefox [task 2023-06-21T04:57:33.890Z] 04:57:33 INFO - Usage: ``` That port is not used anywhere else by geckodriver! But there was a WebSocket port running for the RemoteAgent formerly: https://treeherder.mozilla.org/logviewer?job_id=420098181&repo=mozilla-central&lineNumber=39322 ``` [task 2023-06-21T04:29:35.153Z] 04:29:35 INFO - STDOUT: tests/web-platform/tests/webdriver/tests/bidi/input/perform_actions/key_events.py::test_key_special_key_sends_keydown[F10-expected15] [task 2023-06-21T04:29:35.156Z] 04:29:35 INFO - PID 9254 | 1687321775156 RemoteAgent INFO Perform WebSocket upgrade for incoming connection from 127.0.0.1:37438 ``` This is happening roughly 30 minutes before. First I thought that we might leak some ports but after checking other failing tests this was just an exception. No other test here had an overlap. I pushed a try build with some additional debug logging. Lets see if there might be some insight: https://treeherder.mozilla.org/jobs?repo=try&revision=b222563169748d0968da7fd91a190d202a373270
Bug 1571426 Comment 48 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Hm, that's interesting. So we should not conflate the port that is passed via the capabilities and the actual port used in those tests. The port `59211` above is the one set by wptrunner and which is used for the normal wdspec tests. But for the Mozilla specific classic tests we use the `geckodriver` fixture and that gets its own port by calling the `get_free_port` helper. But there is one interesting case. The port `37438` where we fail to get geckodriver started is here: https://treeherder.mozilla.org/logviewer?job_id=420098181&repo=mozilla-central&lineNumber=266928-266932 ``` [task 2023-06-21T04:57:33.885Z] 04:57:33 INFO - STDOUT: Running command: /builds/worker/fetches/geckodriver --port 37438 -vv --binary /builds/worker/workspace/build/application/firefox/firefox --allow-origins http://web-platform.test:8000 [task 2023-06-21T04:57:33.890Z] 04:57:33 INFO - Test harness output was not a valid structured log message [task 2023-06-21T04:57:33.890Z] 04:57:33 INFO - /builds/worker/fetches/geckodriver: error: Address in use (os error 98) [task 2023-06-21T04:57:33.890Z] 04:57:33 INFO - WebDriver implementation for Firefox [task 2023-06-21T04:57:33.890Z] 04:57:33 INFO - Usage: ``` That port is not used anywhere else by geckodriver! But there was a WebSocket port running for the RemoteAgent formerly: https://treeherder.mozilla.org/logviewer?job_id=420098181&repo=mozilla-central&lineNumber=39322 ``` [task 2023-06-21T04:29:35.153Z] 04:29:35 INFO - STDOUT: tests/web-platform/tests/webdriver/tests/bidi/input/perform_actions/key_events.py::test_key_special_key_sends_keydown[F10-expected15] [task 2023-06-21T04:29:35.156Z] 04:29:35 INFO - PID 9254 | 1687321775156 RemoteAgent INFO Perform WebSocket upgrade for incoming connection from 127.0.0.1:37438 ``` This is happening roughly 30 minutes before. First I thought that we might leak some ports but after checking other failing tests this was just an exception. No other test here had an overlap. I pushed a try build with some additional debug logging. Lets see if there might be some insight: https://treeherder.mozilla.org/jobs?repo=try&revision=4f6179ce7b4f53e7b1ce140f9eb9d8421d3e3f6b