-
-
Notifications
You must be signed in to change notification settings - Fork 764
Error parsing session info from SauceLabs #1608
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
I don't think your issue has anything to do with java client. Please report it to Sauce customer support. |
@mykola-mokhnach The problem is with the parsing of the response. I can't tell what the response is, but from SauceLabs logs it seems to be a valid JSON, so that's why I think this IS a client issue. However, if it's not, then for such a simple test code running on such a known vendor I would think you'll have much more impact solving this with SauceLabs than I would. |
I assume there is some problem while the client fetches the response from their infra. Basically, the error means the java client was expecting to get a valid JSON as a response to createSession call, but got nothing instead. Also, in Appium logs we can see that the correct response has been generated. So the issue must happen somewhere in between the Appium server and the client lib. |
I'll try to reproduce this with C# (Appium 5.0.0-beta01). If it happens there too then the issue is most likely at SauceLabs side, but if not then it means the issue is most likely in the Java client side. |
The root cause is SauceLabs returns HTTP
Default Selenium HTTP client doesn't follow redirects. I'm not sure whether it should be fixed on SauceLabs side, or Selenium client side, or Appium client side. |
BTW changing HTTP client to follow redirects fixes the issue. |
This makes sense if it is necessary to wait longer and to avoid connection timeout. @valfirst Do you know how to enable redirects by default for the Selenium's HTTP client? |
It works in C#, meaning it's a java client issue. |
@valfirst How can I do that? |
AFAIK HTTP client creation options are hardcoded inside Selenium lib and I don't see any simple way to change these. Perhaps we could only add an ugly hack to java-client/src/main/java/io/appium/java_client/remote/AppiumCommandExecutor.java Line 149 in 1586152
|
for now there is no way to enable following redirects in Selenium HTTP client, I've checked my assumption via debug: just changed the client |
Linked the original Selenium's bug. Not sure if it is going to be solved soon though |
Selenium lib got a patch there. We'd have to patch its version for java-client as soon as it reaches release state and push a new beta |
@KazuCocoa Could you please confirm that both HTTP clients in Ruby and Python have redirects handling enabled by default? |
Ruby appium client refers to selenium's one as the default http client. It has https://github.com/SeleniumHQ/selenium/blob/9d9e4c7185cd44aafb18e707a34bcfc851fa9a31/rb/lib/selenium/webdriver/remote/http/default.rb#L104-L109 so Ruby should be ok. |
Python client handles connections via |
I have come across this issue with Serenity BDD (3.1.1) which has Appium java-client: 8.0.0-beta. Here are some observations.
|
Fixes compatibility with saucelabs appium/java-client#1608
Fixes compatibility with saucelabs appium/java-client#1608
Description
When I run the attached code with Appium version 8.0.0-beta on SauceLabs, in the SauceLabs dashboard I see the test running, I see the device launching and the app starting, so I know the session had started. But then the client fails with this error:
See full exception log here: https://gist.github.com/itaibh/5cdf5eb606de58299aed0abb4005c0e0
Environment
I give here sample code that uses the following capabilities:
However, the same issue occurs on other configurations, where the common thing is that I use Appium Java Client 8.0.0-beta and SauceLabs. Notice this doesn't happen on BrowserStack (which is the only other provider I tested on).
Code To Reproduce Issue
Link To Appium Logs
https://gist.github.com/itaibh/d85b1a33257fa5101816f1214a48fda9
The text was updated successfully, but these errors were encountered: