maestro: [v1.30.2] Failed to reach XCUITest Server in restart

Here’s a PR I made which adds iOS support for MAESTRO_DRIVER_STARTUP_TIMEOUT

I got more luck setting MAESTRO_DRIVER_STARTUP_TIMEOUT to 60000

Since I’m not sure how long it might take to get that PR merged, here’s a workaround I came up with you can use when calling maestro:

i=0
while [ $i -le 9 ]; do
maestro test && break
let i=i+1
done

Realistically you can turn down the number of attempts from 9 to something like 2 or 3, but it doesn’t hurt if you’re sure it should be launching. Any previous attempt will have already kicked off the process of launching, so it’s not like you’re rolling the dice and need so many “attempts”. The next try will just piggyback off the headstart.

Of course, this will also re-run the command even if it succeeds to launch but then fails because there were actually failing tests. This solution could be modified, but just FYI. I won’t bother for now, since I’m hoping the PR gets merged before I need it. Right now, I’m only integrating Maestro and only have a single simple test for integration purposes.

I added this loop, the first time I got the java.util.concurrent.TimeoutException: Maestro iOS driver did not start up in time error but then I got this:

java.net.SocketException: Protocol family unavailable
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
	at java.net.Socket.connect(Socket.java:607)
	at okhttp3.internal.platform.Platform.connectSocket(Platform.kt:128)
	at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:295)
	at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
	at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
	at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
	at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
	at okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
	at xcuitest.installer.LocalXCTestInstaller.xcTestDriverStatusCheck(LocalXCTestInstaller.kt:131)
	at xcuitest.installer.LocalXCTestInstaller.isChannelAlive(LocalXCTestInstaller.kt:96)
	at xcuitest.XCTestDriverClient.isChannelAlive(XCTestDriverClient.kt:177)
	at ios.xctest.XCTestIOSDevice.isShutdown(XCTestIOSDevice.kt:174)
	at maestro.cli.session.MaestroSessionManager.createIOS(MaestroSessionManager.kt:311)
	at maestro.cli.session.MaestroSessionManager.createMaestro(MaestroSessionManager.kt:154)
	at maestro.cli.session.MaestroSessionManager.access$createMaestro(MaestroSessionManager.kt:49)
	at maestro.cli.session.MaestroSessionManager$newSession$session$1.invoke(MaestroSessionManager.kt:82)
	at maestro.cli.session.MaestroSessionManager$newSession$session$1.invoke(MaestroSessionManager.kt:81)
	at maestro.cli.db.KeyValueStore.withExclusiveLock(KeyValueStore.kt:37)
	at maestro.cli.session.SessionStore.withExclusiveLock(SessionStore.kt:74)
	at maestro.cli.session.MaestroSessionManager.newSession(MaestroSessionManager.kt:81)
	at maestro.cli.session.MaestroSessionManager.newSession$default(MaestroSessionManager.kt:58)
	at maestro.cli.command.TestCommand.call(TestCommand.kt:136)
	at maestro.cli.command.TestCommand.call(TestCommand.kt:46)
	at picocli.CommandLine.executeUserObject(CommandLine.java:1933)
	at picocli.CommandLine.access$1200(CommandLine.java:145)
	at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2332)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2326)
	at picocli.CommandLine$RunLast.handle(CommandLine.java:2291)
	at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2159)
	at maestro.cli.DisableAnsiMixin$Companion.executionStrategy(DisableAnsiMixin.kt:22)
	at picocli.CommandLine.execute(CommandLine.java:2058)
	at maestro.cli.AppKt.main(App.kt:117)

Any thoughts?

I did see that the PR for MAESTRO_DRIVER_STARTUP_TIMEOUT in iOS is merged. I Have the same issue in iOS 16.2 in Azure pipelines and increasing MAESTRO_DRIVER_STARTUP_TIMEOUT didn’t work. Any ideas?

Since I’m not sure how long it might take to get that PR merged, here’s a workaround I came up with you can use when calling maestro:

i=0
while [ $i -le 9 ]; do
maestro test && break
let i=i+1
done

Realistically you can turn down the number of attempts from 9 to something like 2 or 3, but it doesn’t hurt if you’re sure it should be launching. Any previous attempt will have already kicked off the process of launching, so it’s not like you’re rolling the dice and need so many “attempts”. The next try will just piggyback off the headstart.

Of course, this will also re-run the command even if it succeeds to launch but then fails because there were actually failing tests. This solution could be modified, but just FYI. I won’t bother for now, since I’m hoping the PR gets merged before I need it. Right now, I’m only integrating Maestro and only have a single simple test for integration purposes.