selenium: [🐛 Bug]: downloaded drivers are allegedly not executable

What happened?

I have seen in GitActions unit tests failing in the CI with a ‘RuntimeException: No driver can be provided for capabilities Capabilities …’, e.g.:

So i created a commit to remove the try/catch bock of isAvailable and replaced it with a loop to better hit the issue, see https://github.com/joerg1985/selenium/commit/829fa6347b579f219795d7abca4cfcdc2d178770

After this i did run the ci pipeline and did see this errors a cause:

Is it possible that concurrently calling DriverFinder.getPath will cause this issue? I guess the Selenium Manager does not ensure that other instances of the Selenium Manager have completed, before passing the driver path back to the DriverFinder.getPath? Or is the executable flag some how set asynchronous to creating the file? This might also be a bug in the JDK and the File.canExecute() is outdated.

This might also happen outside the Selenium GitHub unit tests, so i decided to raise this ticket to start investigations.

How can we reproduce the issue?

Cherry pick https://github.com/joerg1985/selenium/commit/829fa6347b579f219795d7abca4cfcdc2d178770 to reproduce in GitHub Actions.

Relevant log output

See above

Operating System

GitHub Actions

Selenium version

trunk

What are the browser(s) and version(s) where you see this issue?

chrome, firefox

What are the browser driver(s) and version(s) where you see this issue?

latest

Are you using Selenium Grid?

No response

About this issue

Original URL
State: open
Created a year ago
Comments: 23 (22 by maintainers)

Most upvoted comments

I think bazel is using multiple processes to run tests in parallel, therefore the singleton does not help to fix

To wait until the driver is executable could be implemented in the selenium manager to have this in one central place. Otherwise it must be implemented for all the client bindings in all languages.

joerg1985 on Aug 26, 2023

This is not the kind of code I’m good at.

Okay, so we might get others into this.

2. I thought there was locking

I am not aware of the rust code, this must someone else check.

3. I thought each process put selenium manager in a different temp directory for this reason

Yes, but this does not cover this case.

4. Or are we talking about driver downloads not being completed by one SM before the next tries to use it because it sees something there?

Yes, i think this is happening here. One SM is still extracting and another SM picks it up before it is ready (marked executable).

5. Would it help or hurt this issue to copy the Selenium manager itself to the /.cache/selenium?

This would probably make it not better

6. Do we want to have a before step in the test suite to load things before they try to be used?

That’s a possible workaround, but others might see this effect too on their CI pipeline.

joerg1985 on Aug 7, 2023