-
-
Notifications
You must be signed in to change notification settings - Fork 409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add retry once with reconnection to the remote debugger to reduce no response condtion error #2334
base: master
Are you sure you want to change the base?
Conversation
I believe this approach could be improved. Obviously the original issue lies somewhere in the remote debugger client implementation, and prevents us from getting a proper response to Runtime.evaluate requests (RD simply does not respond). I believe this might be happening because we don't respect some important event after which such request could be send to a page. Maybe, it is just a classic race condition. For example:
and then we never see any response to the request identified by 24, which means it might be just stuck somewhere inside RD internals since we did not send it in time or did not send it with correct arguments. What we could try now:
|
Let me dig into the response message tonight. After:
was after re-connected one. So the no response was for
Before the I'll split the timeout change as another pr btw. debugging : https://github.com/appium/appium-remote-debugger/compare/debug?expand=1 |
I observed that a remote debugger session could have no response situation by the web inspector. I assumed re-connection and retry again could help for this since the condition did not keep to the next session.
This PR confirmed that when
driver.find_element :xpath, "//*"
got a timeout in the atom execution, reconnected, and re-sent the same request again to the same WebView context; it returned the expected response. My test was a real device. For the simulator, maybe it won't reach this retrial. I haven't observed this case in simulators so far.This behavior is kind of frequently occurs in iOS 17 x Safari 17. Thus, I wondered if we could do this trick as a workaround. Hopefully, Apple will improve this case, but for now, this retrial at least helps our mobile safari/webview automation for iOS 17.
Technically, maybe this can be only for iOS 17/safari 17. iOS 16/Safari 16 is stabler than this iOS/safari 17 case, so the current expectation is iOS 16/safari 16 may not reach the retrial. (No issues exist even iOS 16 and lower reach this retry, so I haven't added version check)
Log with this retrial example. This logs is a recovery case by this PR change.