Skip to content

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

Closed
itaibh opened this issue Dec 8, 2021 · 17 comments · Fixed by #1613
Closed

Error parsing session info from SauceLabs #1608

itaibh opened this issue Dec 8, 2021 · 17 comments · Fixed by #1613

Comments

@itaibh
Copy link

itaibh commented Dec 8, 2021

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:

org.openqa.selenium.SessionNotCreatedException: Could not start a new session. Unable to parse remote response

See full exception log here: https://gist.github.com/itaibh/5cdf5eb606de58299aed0abb4005c0e0

Environment

I give here sample code that uses the following capabilities:

  • IOS 13.0 Simulator
  • Appium 1.17.1

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

import io.appium.java_client.AppiumDriver;
import org.openqa.selenium.MutableCapabilities;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.testng.annotations.Test;
import java.net.URL;

public class TestAppiumOnSauceLabs {
    @Test
    public void TestOnSauce() {
        DesiredCapabilities caps = new DesiredCapabilities();
        caps.setCapability("browserName", "");
        caps.setCapability("name", "iOS Native Demo");
        caps.setCapability("platformName", "iOS");
        caps.setCapability("appium:platformVersion", "13.0");
        caps.setCapability("appiumVersion", "1.17.1");
        caps.setCapability("appium:deviceName", "iPhone XS Simulator");

        MutableCapabilities sauceOpts = new MutableCapabilities();
        sauceOpts.setCapability("username", System.getenv("SAUCE_USERNAME"));
        sauceOpts.setCapability("accessKey", System.getenv("SAUCE_ACCESS_KEY"));
        caps.setCapability("sauce:options", sauceOpts);

        caps.setCapability("app", "https://applitools.jfrog.io/artifactory/Examples/eyes-ios-hello-world/1.2/eyes-ios-hello-world.zip");

        WebDriver driver = null;
        try {
            driver = new AppiumDriver(new URL("https://ondemand.saucelabs.com:443/wd/hub"), caps);
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (driver != null) {
                driver.quit();
            }
        }
    }
}

Link To Appium Logs

https://gist.github.com/itaibh/d85b1a33257fa5101816f1214a48fda9

@mykola-mokhnach
Copy link
Contributor

I don't think your issue has anything to do with java client. Please report it to Sauce customer support.

@itaibh
Copy link
Author

itaibh commented Dec 8, 2021

@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.

@mykola-mokhnach
Copy link
Contributor

mykola-mokhnach commented Dec 8, 2021

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.

@itaibh
Copy link
Author

itaibh commented Dec 8, 2021

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.
In any way, what I wrote about who's having more impact stands, so if we come to a conclusion this is something on SauceLabs side I take it as this is the Appium project responsibility to approach SauceLabs. You can then place the link to the issue or whatever here so I can comment on it or thumb up.

@valfirst
Copy link
Collaborator

valfirst commented Dec 8, 2021

The root cause is SauceLabs returns HTTP 303 with headers like

{
  date=[Wed, 08 Dec 2021 08:08:51 GMT],
  server=[monocle/0.42],
  content-length=[0],
  content-type=[text/html],
  location=[/wd/hub/session/XXXXXXXX-retracted-XXXXXXX]
}

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.

@valfirst
Copy link
Collaborator

valfirst commented Dec 8, 2021

BTW changing HTTP client to follow redirects fixes the issue.

@mykola-mokhnach
Copy link
Contributor

mykola-mokhnach commented Dec 8, 2021

The root cause is SauceLabs returns HTTP 303 with headers like

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?

@itaibh
Copy link
Author

itaibh commented Dec 8, 2021

I'll try to reproduce this with C# (Appium 5.0.0-beta01).

It works in C#, meaning it's a java client issue.

@itaibh
Copy link
Author

itaibh commented Dec 8, 2021

BTW changing HTTP client to follow redirects fixes the issue.

@valfirst How can I do that?

@mykola-mokhnach
Copy link
Contributor

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

(e.g. check if the actual response code == 302 and then try to reload the url)

@valfirst
Copy link
Collaborator

valfirst commented Dec 8, 2021

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

@mykola-mokhnach
Copy link
Contributor

Linked the original Selenium's bug. Not sure if it is going to be solved soon though

@mykola-mokhnach
Copy link
Contributor

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

@mykola-mokhnach
Copy link
Contributor

@KazuCocoa Could you please confirm that both HTTP clients in Ruby and Python have redirects handling enabled by default?

@KazuCocoa
Copy link
Member

KazuCocoa commented Dec 8, 2021

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.
Let me check python soon

@KazuCocoa
Copy link
Member

KazuCocoa commented Dec 8, 2021

Python client handles connections via urllib3 as same as the base selenium client. It sets redirect stuff True by default, so I think python is also ok.

@madhusudhan-patha
Copy link

madhusudhan-patha commented Dec 14, 2021

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.

  1. IOS tests are throwing the error, when executed using SauceLabs, as shown in description ( 303 status code, followed by unable to parse the json response). I have Reported a ticket, not knowing where the issue is coming from, iOS tests are throwing error, but android scripts worked fine using Saucelabs serenity-bdd/serenity-core#2634.
  2. But, Android test scripts got executed with Saucelabs with the same java client version and serenity BDD. It is not giving any redirect status codes or json parsing errors

alvarezguille added a commit to vaadin/testbench that referenced this issue Jan 19, 2022
alvarezguille added a commit to vaadin/testbench that referenced this issue Jan 19, 2022
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants