Open chippers opened 2 years ago
Maybe tauri driver shouldn't be killed at "afterSession()" but instead after the whole test suite is finished? This way, it's okay to "sleep" for 1 second (at most) to let tauri-driver start, and then run the whole suite, and the driver is only killed once afterwards.
WDYT?
I hit the same issue.
The test works on my local Windows 10 PC, but not work on Github hosted windows-latest
VM.
Describe the bug
Based on a Twitter thread about using WebDriver, a developer seems to have run into a timing issue while running a WebdriverIO test suite on Windows in CI. Link to the failed CI run. Based on the logs, it seems like the following likely took place:
tauri-driver
using thebeforeSession
function from the configtauri-driver
is startedtauri-driver
starts the native WebDriver tool (msedgedriver.exe)tauri-driver
is killed based on theafterSession
function from the configtauri-driver
tauri-driver
is startedtauri-driver
starts msedgedriver.exetauri-driver
to msedgedriver.exe to run and pass the testIn short, my conclusion is that there is likely a timing issue between starting
tauri-driver
and it starting the native WebDriver which causes the test suite to try and communicate with it before it is ready. The second test likely passed because it used the native WebDriver started in the first test and both it andtauri-driver
were ready. I cannot reproduce this locally so this is all speculation based on the CI log output and my current understanding of how the typical workflow goes for the test suite.Reproduction
Cannot reproduce locally. See log here.
Expected behavior
Both tests should pass. The native WebDriver should not fail to start after the first one should have been killed.
Platform and versions
Stack trace
Additional context
I'm not sure what the solution is. The desired behavior change seems to be two things, for starters
tauri-driver
to communicate that both itself and the child-process running the native WebDriver server is readytauri-driver
being killed along with the child process which should be killed with it.Being not able to reproduce it locally will make it annoying to debug and validate that these fixes addressed the underlying problem. Not sure if it can even be reliably reproduced on CI.