[🐛 Bug]: java.io.UncheckedIOException: java.io.IOException: HTTP/1.1 header parser received no bytes about selenium HOT 47 CLOSED

Hello I am an engineer at Disney and I am getting the same error. Please forgive me if I am being naive, it is my first time looking this closely at the Selenium code.

My setup is pretty simple:
Appium Java client -> selenium hub -> selenium node relay -> appium 2.5.4

I believe @titusfortner is correct. There was a previous bug submitted by @mykola-mokhnach (#12918) that talked about needing a solution for forcing HTTP/1.1. A workaround was put in place which allows someone to specifically force HTTP/1.1 on the JdkHttpClient. This was then implemented in the Appium Java client so now when a message is sent from that client, there is no Connection: Upgrade, HTTP2-Settings sent with the call. The problem I am having is that when the HUB receives that message, it's JdkHttpClient doesn't seem to be configured to do the same thing, so it passes the Connection: Upgrade, HTTP2-Settings along to the selenium node relay which then propagates that to the Appium server which cannot handle HTTP/2 connections at this time. Calls made directly from the selenium node relay to Appium (which do not originate from the HUB) do not include Connection: Upgrade, HTTP2-Settings, I'm assuming because the node allows you configure the protocol-version.

If the HUB configuration were to allow us to specify the version the same way we can in the Java Webdriver client or the node configuration, then we may be able to force HTTP/1.1 all the way through the stack.

I ran tcpdump on my selenium hub and selenium node relay instances and can provide those logs if necessary.

from selenium.

I can confirm that my scenario is now working with 4.21.0. @joerg1985 Thank you for your assistance!

from selenium.

Thank you

from selenium.

@titusfortner I have recently merged the fix appium/appium#20142 from the Appium server side. It should address this issue once and forever.

from selenium.

@alokkr016, thank you for creating this issue. We will troubleshoot it as soon as we can.

from selenium.

What is programmatically and what is manually? Can you actually share the details and just not dump a stacktrace?

from selenium.

I have set up three iOS nodes and I'm running five test cases. To automate this process, I've created a shell script containing grid and node commands, which I'm executing programmatically using Java. Additionally, I've launched three iOS devices. While the test cases are running successfully on two of the devices, one device is experiencing issues. Interestingly, when I manually run the grid command and Appium server command in the terminal, the tests are distributed perfectly across all three devices."

from selenium.

If I understand correctly, launching every process on the terminal works, but it fails when you use the script you created. Why would that be related to Selenium Grid?

from selenium.

Because with the help of my script I am able to launch the simulator, launch the grid, and register the node. However, when I am creating the driver for the device 1, I am facing an exception.

from selenium.

Why don't you share the script? We could help with something, perhaps.

from selenium.

Here is my sample script file
Could you please check and provide me with valuable suggestions

I am sorry, but I do not even understand several pieces of the script. I cannot give suggestions because there is a lot of context I do not have. My recommendation is to start small and after you get everything running manually and successfully, break the manual steps one by one into scrips so you can track when it starts to fail.

As it stands, I do not understand why this is a Selenium Grid issue, given that the error happens only when your script is used.

from selenium.

@diemol

Just wanted to add my 5 cents to this issue.

the exceptions happens at

Could you please confirm this client actually picks up the protocol-version value from the node config in the hub version being used by the issue creator?

from selenium.

@alokkr016 i had a short look at the script and i am wondering why you do not pass the hub url to the node?

I would suggest to redirect the output of the node to a file and check whether it does start or the startup fails.

from selenium.

@mykola-mokhnach yes, a few lines above.

from selenium.

@joerg1985 Even though I am specifying the hub URL as --hub http://<hub-ip>:4444, the test cases are still failing on the first device. Additionally, I am encountering the same exception:

org.openqa.selenium.SessionNotCreatedException: Could not start a new session. Response code 500. Message: Could not start a new session. Could not start a new session. Error while creating session with the service http://127.0.0.1:8232. java.io.IOException: HTTP/1.1 header parser received no bytes.

from selenium.

@alokkr016 how about the logs of the node?

from selenium.

@joerg1985
file.txt

from selenium.

From the logs:
Appium REST http interface listener started on http://0.0.0.0:4724
Appium REST http interface listener started on http://0.0.0.0:4725

From the error message:
23:44:47.799 WARN [SeleniumSpanExporter$1.lambda$export$1] - Error while creating session with the service http://127.0.0.1:4723. java.io.IOException: HTTP/1.1 header parser received no bytes

So i would suggest to check the generated config / toml files, there should be a missmatch in the ports.

from selenium.

Everything is okay. Each configuration has a different port number, UDID, and version. There are no issues with the configurations, still it's not working

from selenium.

Thank you for the feedback, I am closing this issue.

from selenium.

what is the fix here?

from selenium.

I think this was closed by mistake; the OP said it is still not working for them, and there's now a Sauce Labs user getting the same error.

Also, the lack of http 2 support in Appium seems like a pretty big deal. @jlipps have you considered updating to a better maintained http server if the one you're using can't support it?

from selenium.

Also, the lack of http 2 support in Appium seems like a pretty big deal. @jlipps have you considered updating to a better maintained http server if the one you're using can't support it?

This would be a major change in the server architecture, which also might lead to major changes in official and third party components, which we want to avoid. Currently Appium uses Express.js 4 as its HTTP framework. Unfortunately it is currently in maintenance mode and its successor (Express.js 5) is still in the early beta stage: expressjs/express#4920

So, the question here is whether we'd like to keep it stable or to make it modern, but with the risk of losing stability.

I've also mentioned it once that there is a possibility to add HTTP/2 support to the current Express.js 4 - based implementation by enabling server-side HTTPS. See https://github.com/appium/appium/blob/master/packages/appium/docs/en/guides/tls.md

from selenium.

@littlegeek01 did you try to set the protocol-version inside the relay config (available since v4.20.0)?

@mykola-mokhnach why not dropping the http/2 headers in the appium server like the selenium server does? see

Should the relay config default to http1.1 as appium is (in my mind) the main usecase for this and selenium itself does not use nor benefit from http/2? Some drivers do not even fully implement http1.1 (e.g. chunked requests), i don't think they will start to implement http/2.

from selenium.

Hello @joerg1985: I did set the protocol-verson on the relay config; however, that doesn't seem to be where the problem lies. All traffic originating from the relay correctly forces HTTP/1.1 (the /status call that is made to Appium), it's only the traffic that is coming from the HUB that is the problem. I don't see any way to force the protocol version on the HUB, which is reflected in the configuration matrix provided here: https://www.selenium.dev/documentation/grid/configuration/cli_options/

from selenium.

@joerg1985, I encountered a similar issue despite enforcing HTTP/1.1 in the protocol version. While all test cases are executing flawlessly on Android, I am experiencing this problem with iOS.

from selenium.

@littlegeek01 there should be no direct traffic from the HUB to Appium, everything should passed through the relay.
As long as the direct connect feature is not used, are you using this feature?
https://github.com/appium/java-client/blob/a67dd969a6252806a14d9adaf09d78f2147fba8d/src/main/java/io/appium/java_client/AppiumClientConfig.java#L177-L185

@alokkr016 are you using direct connect? see link above

from selenium.

No @joerg1985 I am not using direct connect

from selenium.

@joerg1985 In my setup there is no traffic going directly from the HUB to Appium. All traffic goes through the node relay. The distinction in traffic is where it originates. If traffic comes from my client, through the hub, through the node relay, then it fails. If traffic comes from the node relay to Appium, then things are fine.

For example:
The node relay makes a periodic call to the /status endpoint on Appium. Since this traffic originates from the node relay, there is no problem. When I make a call from my java client to start a session, the traffic originates from my application server, goes to selenium hub, then goes to selenium node relay, then to Appium. This call fails because somewhere along the way (I believe in the hub) the protocol no longer gets forced to HTTP/1.1. When I was doing my TCP tracing, it was the hub that started adding on the Connection: Upgrade, HTTP2-Settings header.

from selenium.

One more thing I want to mention:

I get org.asynchttpclient.exception.RemotelyClosedException: Remotely closed when I use the selenium-grid-server version that did not have the protocol-version enforced in the node configuration. I tried(4.13.0, 4.10.0)

23:47:23.507 WARN [SeleniumSpanExporter$1.lambda$export$1] - Error while creating session with the service http://127.0.0.1:4723. org.asynchttpclient.exception.RemotelyClosedException: Remotely closed
23:47:23.507 WARN [SeleniumSpanExporter$1.lambda$export$1] - java.io.UncheckedIOException: org.asynchttpclient.exception.RemotelyClosedException: Remotely closed
	at org.openqa.selenium.remote.http.netty.NettyHttpHandler.makeCall(NettyHttpHandler.java:73)
	at org.openqa.selenium.remote.http.AddSeleniumUserAgent.lambda$apply$0(AddSeleniumUserAgent.java:42)
	at org.openqa.selenium.remote.http.Filter.lambda$andFinally$1(Filter.java:55)
	at org.openqa.selenium.remote.http.netty.NettyHttpHandler.execute(NettyHttpHandler.java:48)
	at org.openqa.selenium.remote.http.AddSeleniumUserAgent.lambda$apply$0(AddSeleniumUserAgent.java:42)
	at org.openqa.selenium.remote.http.Filter.lambda$andFinally$1(Filter.java:55)
	at org.openqa.selenium.remote.http.netty.NettyClient.execute(NettyClient.java:97)
	at org.openqa.selenium.remote.tracing.TracedHttpClient.execute(TracedHttpClient.java:54)
	at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:115)
	at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:96)
	at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:68)
	at org.openqa.selenium.grid.node.relay.RelaySessionFactory.apply(RelaySessionFactory.java:164)
	at org.openqa.selenium.grid.node.relay.RelaySessionFactory.apply(RelaySessionFactory.java:72)
	at org.openqa.selenium.grid.node.local.SessionSlot.apply(SessionSlot.java:147)
	at org.openqa.selenium.grid.node.local.LocalNode.newSession(LocalNode.java:467)
	at org.openqa.selenium.grid.node.NewNodeSession.execute(NewNodeSession.java:50)
	at org.openqa.selenium.remote.http.Route$TemplatizedRoute.handle(Route.java:193)
	at org.openqa.selenium.remote.http.Route.execute(Route.java:69)
	at org.openqa.selenium.grid.security.RequiresSecretFilter.lambda$apply$0(RequiresSecretFilter.java:62)
	at org.openqa.selenium.remote.tracing.SpanWrappedHttpHandler.execute(SpanWrappedHttpHandler.java:91)
	at org.openqa.selenium.remote.http.Filter$1.execute(Filter.java:63)
	at org.openqa.selenium.remote.http.Route$CombinedRoute.handle(Route.java:347)
	at org.openqa.selenium.remote.http.Route.execute(Route.java:69)
	at org.openqa.selenium.grid.node.Node.execute(Node.java:262)
	at org.openqa.selenium.remote.http.Route$CombinedRoute.handle(Route.java:347)
	at org.openqa.selenium.remote.http.Route.execute(Route.java:69)
	at org.openqa.selenium.remote.AddWebDriverSpecHeaders.lambda$apply$0(AddWebDriverSpecHeaders.java:35)
	at org.openqa.selenium.remote.ErrorFilter.lambda$apply$0(ErrorFilter.java:44)
	at org.openqa.selenium.remote.http.Filter$1.execute(Filter.java:63)
	at org.openqa.selenium.remote.ErrorFilter.lambda$apply$0(ErrorFilter.java:44)
	at org.openqa.selenium.remote.http.Filter$1.execute(Filter.java:63)
	at org.openqa.selenium.netty.server.SeleniumHandler.lambda$channelRead0$0(SeleniumHandler.java:44)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:842)
Caused by: org.asynchttpclient.exception.RemotelyClosedException: Remotely closed
	at org.asynchttpclient.exception.RemotelyClosedException.INSTANCE(Unknown Source)

from selenium.

@littlegeek01 The /status endpoint is handled by the appium server and not passed to the mobile device. So the connection from Appium to the mobile device might fail.

from selenium.

@joerg1985 I think the relevant info is the headers that are sent. We already know that Appium cannot handle the 'Connection: Upgrade, HTTP2-Settings' header. When the /status endpoint is called from the node relay, the GET request does not include that header. When the node relay proxies commands from the hub it does include that header. I don't think that the device is involved at all in this scenario.

from selenium.

@littlegeek01 the ReverseProxyHandler used by the relay to handle these requests (from the hub to the relay) will remove these headers so they should not be proxied to the appium server. The client used to send it to the appium server should pick up the protocol version from the relay config and not add them again.
Do you have tcpdumps from the relay to appium server?

from selenium.

sorry about the long post, but here are the relevant tcpdump logs.

IP addresses have been obfuscated
10.1.1.1 Java clent
10.2.2.2 Selenium Hub
10.3.3.3 Selenium Node Relay and Appium Server


**----- original call from java client to hub -----**

14:46:30.093279 IP 10.1.1.1.49631 > 10.2.2.2.4444: Flags [P.], seq 0:232, ack 1, win 2060, options [nop,nop,TS val 4137319833 ecr 240383934], length 232
[email protected]...
.04
.ik...\W..=.7`.....c......
..}..S..POST /session HTTP/1.1
Content-Length: 608
Host: 10.2.2.2:4444
Content-Type: application/json; charset=utf-8
User-Agent: appium/9.0.0 (selenium/4.14.1 (java mac))
X-Idempotency-Key: 443a1cb7-51db-4268-b8a0-c281827523e1

14:46:30.093373 IP 10.1.1.1.49631 > 10.2.2.2.4444: Flags [P.], seq 232:840, ack 1, win 2060, options [nop,nop,TS val 4137319833 ecr 240383934], length 608
[email protected]...
.04
.ik...\W.	%.7`......I.....
..}..S..{
  "capabilities": {
    "firstMatch": [
      {
      }
    ],
    "alwaysMatch": {
      "appium:appActivity": "com.appetizeactivate.android.main.retail.MainRetailActivity",
      "appium:appPackage": "com.appetizeactivate.android.debug",
      "appium:automationName": "UiAutomator2",
      "appium:deviceName": "Android",
      "appium:dontStopAppOnReset": false,
      "appium:fullReset": false,
      "appium:noReset": true,
      "appium:platformVersion": "11.0",
      "appium:settings[imageMatchThreshold]": 0.6,
      "appium:udid": "10.9.9.9:1234",
      "platformName": "ANDROID"
    }
  }
}


**----- call from hub to node relay -----**

14:46:30.110457 IP 10.2.2.2.33614 > 10.3.3.3.5555: Flags [P.], seq 1494:1825, ack 3293, win 849, options [nop,nop,TS val 240383988 ecr 240363794], length 331
E.....@.@..
.ik
.h..N..<.p..\.....Q.......
.S...S..POST /se/grid/node/session HTTP/1.1
Connection: Upgrade, HTTP2-Settings
Content-Length: 585
Host: 10.3.3.3:5555
HTTP2-Settings: AAEAAEAAAAIAAAABAAMAAABkAAQBAAAAAAUAAEAA
Upgrade: h2c
traceparent: 00-9f1f84c2833fdb6a7bba3ca9a05c45ef-95bb81be80ac15f2-01
User-Agent: selenium/4.20.0 (java unix)
X-REGISTRATION-SECRET:


14:46:30.110500 IP 10.2.2.2.33614 > 10.3.3.3.5555: Flags [P.], seq 1825:2410, ack 3293, win 849, options [nop,nop,TS val 240383988 ecr 240363794], length 585
E..}..@.@..

.ik
.h..N..<.q..\.....Q.......
.S...S..{
  "metadata": {
  },
  "desiredCapabilities": {
    "appium:appActivity": "com.appetizeactivate.android.main.retail.MainRetailActivity",
    "appium:appPackage": "com.appetizeactivate.android.debug",
    "appium:automationName": "UiAutomator2",
    "appium:deviceName": "Android",
    "appium:dontStopAppOnReset": false,
    "appium:fullReset": false,
    "appium:noReset": true,
    "appium:platformVersion": "11.0",
    "appium:settings[imageMatchThreshold]": 0.6,
    "appium:udid": "10.9.9.9:1234",
    "platformName": "ANDROID"
  },
  "downstreamDialects": [
    "W3C"
  ]
}

**----- incoming call from hub to node relay -----**

14:46:30.110508 IP 10.2.2.2.33614 > 10.3.3.3.5555: Flags [P.], seq 1494:1825, ack 3293, win 849, options [nop,nop,TS val 240383988 ecr 240363794], length 331
E.....@.@..
.ik
.h..N..<.p..\.....Q.j.....
.S...S..POST /se/grid/node/session HTTP/1.1
Connection: Upgrade, HTTP2-Settings
Content-Length: 585
Host: 10.3.3.3:5555
HTTP2-Settings: AAEAAEAAAAIAAAABAAMAAABkAAQBAAAAAAUAAEAA
Upgrade: h2c
traceparent: 00-9f1f84c2833fdb6a7bba3ca9a05c45ef-95bb81be80ac15f2-01
User-Agent: selenium/4.20.0 (java unix)
X-REGISTRATION-SECRET:


14:46:30.110543 IP 10.2.2.2.33614 > 10.3.3.3.5555: Flags [P.], seq 1825:2410, ack 3293, win 849, options [nop,nop,TS val 240383988 ecr 240363794], length 585
E..}..@.@..

.ik
.h..N..<.q..\.....Q.Z.....
.S...S..{
  "metadata": {
  },
  "desiredCapabilities": {
    "appium:appActivity": "com.appetizeactivate.android.main.retail.MainRetailActivity",
    "appium:appPackage": "com.appetizeactivate.android.debug",
    "appium:automationName": "UiAutomator2",
    "appium:deviceName": "Android",
    "appium:dontStopAppOnReset": false,
    "appium:fullReset": false,
    "appium:noReset": true,
    "appium:platformVersion": "11.0",
    "appium:settings[imageMatchThreshold]": 0.6,
    "appium:udid": "10.9.9.9:1234",
    "platformName": "ANDROID"
  },
  "downstreamDialects": [
    "W3C"
  ]
}

**----- call from node relay to Appium -----**

14:46:30.114345 IP 127.0.0.1.35060 > 127.0.0.1.4723: Flags [P.], seq 1:337, ack 1, win 342, options [nop,nop,TS val 240390644 ecr 240390643], length 336
E....;@[email protected].....{.I...V.x.....
.T...T..POST /session HTTP/1.1
Connection: Upgrade, HTTP2-Settings
Content-Length: 645
Host: localhost:4723
HTTP2-Settings: AAEAAEAAAAIAAAABAAMAAABkAAQBAAAAAAUAAEAA
Upgrade: h2c
content-type: application/json; charset=utf-8
traceparent: 00-9f1f84c2833fdb6a7bba3ca9a05c45ef-01a17c9bea696435-01
User-Agent: selenium/4.20.0 (java unix)


14:46:30.114357 IP 127.0.0.1.4723 > 127.0.0.1.35060: Flags [.], ack 337, win 350, options [nop,nop,TS val 240390644 ecr 240390644], length 0
E..4..@.@.+..........s...{.I.......^.(.....
.T...T..
14:46:30.114399 IP 127.0.0.1.35060 > 127.0.0.1.4723: Flags [P.], seq 337:982, ack 1, win 342, options [nop,nop,TS val 240390644 ecr 240390644], length 645
E....<@[email protected].....{.I...V.......
.T...T..{
  "capabilities": {
    "firstMatch": [
      {
        "appium:appActivity": "com.appetizeactivate.android.main.retail.MainRetailActivity",
        "appium:appPackage": "com.appetizeactivate.android.debug",
        "appium:automationName": "UiAutomator2",
        "appium:deviceName": "Android",
        "appium:dontStopAppOnReset": false,
        "appium:fullReset": false,
        "appium:newCommandTimeout": "180",
        "appium:noReset": true,
        "appium:platformVersion": "11.0",
        "appium:settings[imageMatchThreshold]": 0.6,
        "appium:udid": "10.9.9.9:1234",
        "platformName": "ANDROID"
      }
    ]
  }
}


**----- status call from node relay to Appium -----**

15:02:03.261133 IP 127.0.0.1.35748 > 127.0.0.1.4723: Flags [P.], seq 1:177, ack 1, win 342, options [nop,nop,TS val 241323791 ecr 241323791], length 176
E.....@[email protected].......
.bO..bO.GET /status HTTP/1.1
Content-Length: 0
Host: localhost:4723
traceparent: 00-2d2b25c1f6b6e9ecfdbbe522b7f4ba51-1abe3fe607af65c8-01
User-Agent: selenium/4.20.0 (java unix)


15:02:03.261142 IP 127.0.0.1.4723 > 127.0.0.1.35748: Flags [.], ack 177, win 350, options [nop,nop,TS val 241323791 ecr 241323791], length 0
E..4.y@[email protected]..]...^.(.....
.bO..bO.
15:02:03.262670 IP 127.0.0.1.4723 > 127.0.0.1.35748: Flags [P.], seq 1:349, ack 177, win 350, options [nop,nop,TS val 241323792 ecr 241323791], length 348
E....z@[email protected]..]...^.......
.bO..bO.HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 110
ETag: W/"6e-aL0SN09TRDa5glNc4iIg/oKGoHk"
Date: Thu, 23 May 2024 15:02:03 GMT
Connection: keep-alive
Keep-Alive: timeout=600

{"value":{"ready":true,"message":"The server is ready to accept new connections","build":{"version":"2.5.1"}}}


**----- selenium node config -----**

[node]
detect-drivers = false

[relay]
# Default Appium server endpoint
url = "http://localhost:4723"
status-endpoint = "/status"
protocol-version = "HTTP/1.1"
# Stereotypes supported by the service. The initial number is "max-sessions", and will allocate
# that many test slots to that particular configuration
configs = [
  "1", "{\"platformName\":\"Android\", \"appium:automationName\": \"UiAutomator2\",\"appium:appPackage\": \"com.myobfuscated.package\",\"appium:appActivity\": \"com.another.obfuscated.package\",\"appium:noReset\": true,\"appium:fullReset\": false,\"appium:dontStopAppOnReset\": false, \"appium:newCommandTimeout\": \"180\",\"appium:udid\": \"10.9.9.9:1234\",\"appium:platformVersion\": \"11.0\"}"
]

from selenium.

@littlegeek01 thanks for the dump, i think i found it. The new session request does respect the service protocol from v4.21.0 (fe2edbd) and you are using v4.20.0. The status endpoint does respect it from v4.20.0 (7dd6163)

from selenium.

@joerg1985 Thank you for the info. Will upgrade and try again.

from selenium.

@joerg1985, I am encountering the following error with version 4.21.0: java.io.UncheckedIOException: java.io.IOException: HTTP/1.1 header parser received no bytes

from selenium.

@alokkr016 could you share your generated toml files and the coresponding logs of one run? The logs last time did not show appium to start at the port the relay was trying to connect.

from selenium.

@joerg1985 have a look
Config files : https://gist.github.com/alokkr016/477d8b5b42a7a93294b613f92d47522b
Log : https://gist.github.com/alokkr016/876359e057fb6dc8794a756ab044645e

Note : I am facing the problem on iOS only not on android

from selenium.

@alokkr016 i only see the start of two appium instances again.

Appium REST http interface listener started on http://0.0.0.0:4724
Appium REST http interface listener started on http://0.0.0.0:4725

The one selenium is trying to connect should be running on 4723 and there is also a toml file for this.
But it seems like it does not start for what ever reason, could you add more logging to the script?
After starting the appium server you could try to connect to the status endpoint (curl -v http://127.0.0.1:4723/status) to ensure it is running.

from selenium.

Can you tell me the reason for this, as all three nodes are being added?

from selenium.

Could you try to start the missing appium server manually and see what the output is?

from selenium.

The Appium server is running, and nodes are being registered. However, when the driver instance is created, the first Appium server crashes, resulting in only the last two test cases running. If I set the thread count to 1, none of the test cases run. This issue occurs only with iOS; Android is working fine.

xcuiTestOptions.setPlatformName(Platform.IOS.name()); xcuiTestOptions.setApp(System.getProperty("user.dir") + "/src/test/resources/app/Demo-nowiremock.app"); xcuiTestOptions.autoAcceptAlerts(); xcuiTestOptions.setAutomationName(AutomationName.IOS_XCUI_TEST); xcuiTestOptions.setWdaLaunchTimeout(Duration.ofSeconds(60)); xcuiTestOptions.setNewCommandTimeout(Duration.ofSeconds(30)); xcuiTestOptions.setNoReset(false);

These are the capabilities I am using. What should I add or remove? Can you please suggest?

from selenium.

Sounds like a appium issue to me, so i can not help further.

from selenium.

@joerg1985 is this a good summary of where we are?

• As of 4.20 a protocol version gets set by default to address (#13481)
• Relay wasn't actually setting the version in the client config which was fixed in 4.21 (#13880)
• There is still something that Appium does not like with these changes

from selenium.

@alokkr016 does this work with the newly released Appium 2.6?

from selenium.

This issue was closed because we did not receive any additional information after 14 days.

from selenium.