WDA session stuck 20s at first try and fails, then, after retry it works

The problem

At running a test, the WDA is being installed and run, the app is open on the iPhone but nothing happens about 20s. Then, after auto-restart of the WDA session, everything works fine.

When the WDA session is stuck, I do request to the WDA using Postman, postman shows pending response until the 20s is reached, then it returns correct data.

Seems WDA is busy for 20s at first try, then, after that busy session is terminated and the new one is started as wdaStartupRetries=3, that second session works normal.

Same happens at Appium Desktop run, first time opening a connection, the Inspector is unable to load the content and the screenshot, but when I kill the session and start again, it works normally.

Environment

• Appium version (or git revision) that exhibits the issue: v1.20.0
• Last Appium version that did not exhibit the issue (if applicable): -
• Desktop OS/version used to run Appium: Mac, iOS-14.3
• Node.js version (unless using Appium.app|exe): v15.5.1
• Npm or Yarn package manager: npm -v = 7.3.0
• Mobile platform/version under test: iOS
• Real device or emulator/simulator: device
• Appium CLI or Appium.app|exe: CLI an Desktop

Details

First session logs which show the WDA stuck moment

2021-02-10 20:38:35:966 - [debug] [WD Proxy] Proxying [GET /wda/screen] to [GET http://127.0.0.1:8106/session/0E449474-55C0-42B8-BFE6-850C87F52221/wda/screen] with no body
2021-02-10 20:38:35:974 - [Xcode] 2021-02-10 20:38:35.891890+0400 WebDriverAgentRunner-Runner[9972:7631066] Getting the most recent active application (out of 1 total items)
2021-02-10 20:38:35:974 - [Xcode]
2021-02-10 20:38:35:985 - [Xcode]     t =     8.10s Get all elements bound by accessibility element for: Descendants matching type StatusBar
2021-02-10 20:38:35:985 - [Xcode]
2021-02-10 20:38:59:011 - [HTTP] --> GET /wd/hub/status
2021-02-10 20:38:59:012 - [HTTP] {}

You see time jump from 20:38:35 to 20:38:59 During that 24 seconds the app did nothing, it was on the first page.

WDA could not response to GET http://127.0.0.1:8106/session/0E449474-55C0-42B8-BFE6-850C87F52221/wda/screen

The next line was

[HTTP] --> GET /wd/hub/status

Second session logs which show the WDA responded correcly

2021-02-10 20:40:57:523 - [Xcode]
2021-02-10 20:40:57:593 - [debug] [WD Proxy] Got response with status 200: {"value":{"sessionId":"E4066E22-82A9-4EF1-963C-A5A81D19D400","capabilities":{"device":"iphone","browserName":"app","sdkVersion":"14.3","CFBundleIdentifier":"bundleId"}},"sessionId":"E4066E22-82A9-4EF1-963C-A5A81D19D400"}
2021-02-10 20:40:57:605 - [debug] [WD Proxy] Proxying [GET /wda/screen] to [GET http://127.0.0.1:8106/session/E4066E22-82A9-4EF1-963C-A5A81D19D400/wda/screen] with no body
2021-02-10 20:40:57:617 - [Xcode] 2021-02-10 20:40:57.533889+0400 WebDriverAgentRunner-Runner[9972:7631066] Getting the most recent active application (out of 1 total items)
2021-02-10 20:40:57:617 - [Xcode]
2021-02-10 20:40:57:619 - [Xcode]     t =   149.73s Get all elements bound by accessibility element for: Descendants matching type StatusBar
2021-02-10 20:40:57:619 - [Xcode]     t =   149.74s     Requesting snapshot of accessibility hierarchy for app with pid 59
2021-02-10 20:40:57:619 - [Xcode]
2021-02-10 20:40:57:653 - [Xcode]     t =   149.77s     Find: Descendants matching type StatusBar
2021-02-10 20:40:57:653 - [Xcode]
2021-02-10 20:40:57:667 - [Xcode]     t =   149.78s Checking existence of `StatusBar`
2021-02-10 20:40:57:667 - [Xcode]

You see there is no time jump the WDA was able to response to GET http://127.0.0.1:8106/session/E4066E22-82A9-4EF1-963C-A5A81D19D400/wda/screen

The return was

[Xcode] t = 149.74s Requesting snapshot of accessibility hierarchy for app with pid 59

UPDATE When the WDA is stuck at the first run, the app isn’t hang, I can click and work on it.

Links to Appium logs

first_WDA_stuck.log fist_page_ios_stuck_SHOW_IOS_LOG fist_page_ios_stuck_SHOW_IOS_LOG__SHOW_XCODE_LOG

[KazuCocoa]

The name was changed to appium:includeDeviceCapsToSessionInfo, but you can try it out with current appium@beta (as xcuitest-driver 3.37.0). We’d like to work to the false behaviour by default, but thanks for letting us this issue.

[uterator]

Thanks @KazuCocoa for the commit, the results are good.

My setup is

appium-webdriveragent:master 4eed2c857b276c1667839b3afd8ca63cf58a6f46
appium-xcuitest-driver:ignore-screen e51c8d1dbe450bc1a185254468c5245050b2a2da

With includeScreenInfoInSession = false. There is no restart of the WDA session to access elements. The app is able to pass the first screen at the very beginning and continue the test. The session starts, the test continues and doesn’t interrupt, which is very good. output_with_includeScreenInfoInSession_false_set.log

Without setting “includeScreenInfoInSession”. The app behaves as before, with delay and with WDA session restart before the test is able to continue. output_without_includeScreenInfoInSession_false_set.log

Thank you very much!