[🐛 Bug]: Selenium 4.32.0 ruby bindings fail to start firefox in parallel testing #15707
Labels
C-rb
Ruby Bindings
D-firefox
I-defect
Something is not working as intended
I-regression
Something was working but we "fixed" it
OS-linux
R-help wanted
Issues looking for contributions
Comments
tomhughes
added
I-defect
|
@tomhughes, thank you for creating this issue. We will troubleshoot it as soon as we can. Selenium Triage Team: remember to follow the Triage Guide |
github-actions
bot
added
C-rb
8 tasks
|
Ah, right. There's a race condition between asking for an unused port over 9222, and one of the processes actually locking that port. @p0deje is there a reason we don't make this random? (Doesn't actually fix the race condition, but might make it harder to hit). I know the other bindings use random ports in their implementations. The only way to ensure there is no collision is to manage the websocket ports in the client, code. |
titusfortner
added
R-help wanted
|
This issue is looking for contributors. Please comment below or reach out to us through our IRC/Slack/Matrix channels if you are interested. |
|
Does the selenium code actually need to know the port number? As far as I could see nothing actually connects to it? If that is the case then |
|
I thought @whimboo said that using 0 wasn't sufficient. |
|
Using port We do not have a solution for that yet. |
|
So, first we need to allow users to pass in a websocket-port value that we do not override, so have to check that args doesn't include websocket-port Then set the default to 0 @tomhughes would you be interested in creating a PR for this? |
|
Normally I'd be happy to try but I'm afraid your build/test system has defeated me... I did eventually manage to get bazel installed but it just fails to build anything with pages of errors and then skips all the tests. |
|
I think the main problem may be this causing compiles to fail: but I have no idea why it thinks my filesystem is readonly and in any case I have removed ccache from my path now and it's still doing the same. |
|
Here's the full log: |
|
Can you try running bazel build with |
|
I blew away which I fear is because it's trying to compile ruby 3.1 (why a three old version? why are we building ruby from source when I have a perfectly good one?) with gcc 15 and is running into https://gcc.gnu.org/gcc-15/porting_to.html#c23-fn-decls-without-parameters. |
|
The idea is to be able to have hermetic installs of all the languages used by selenium so devs don't have to set up individual dev environments for everything. Ruby makes that challenging because it references local libraries for a lot of things. And 3.1 because we need to make sure that the syntax works for people using the oldest supported version (technically 3.2 now, we have a PR to update that) Maybe we do just switch to using JRuby for the default, @p0deje ? We can toggle to MRI on github actions tests? |
|
@titusfortner we can, but your RubyMind will break :) @tomhughes Can you please try switch to JRuby and see if it helps? To do that, simply run the following: |
|
I'll just overwrite it when I need to test locally |
|
I gave up trying to get anything to run locally and I've opened #15727 and we'll see what GHA makes of the tests... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Selenium 4.32.0 attempts to address issues with Firefox 136 and later failing when more that one instance is started (see mozilla/geckodriver#2218 for details) by allocating a unique bidi port for each instance in #15458.
That works fine if all the instances are started in a single thread but fails if two threads are starting instances simultaneously as
PortProberworks by allocating and then immediately closing a port leaving another thread free to do the same thing in the gap before firefox starts and binds it.Reproducible Code
Debugging Logs
I added
puts command.inspectto thebuild_processmethod inServiceManagerin order to see what processes were being started and then ran my test suite single threaded:and then I repeated the same with multiple threads:
As you can see in the second case multiple instances were started using the same bidi port and tests then started failing en mass as most of the firefox instances had failed to start.
ℹ️ Last known working version:
4.31.0 with firefox < 136 or a monkey patch to add `--websocket-port=0`The text was updated successfully, but these errors were encountered: