browserTimeout parameter and BROWSER_TIMEOUT reason are confusing and inconsistent

[kool79]

1. Parameter browserTimeout does nothing (actually not used).
   The last time it was used is pre-3.9 version in java/server/src/org/openqa/selenium/remote/server/DriverServlet.java, (file deleted in commit 0811736)
   Currently both OKHttp and Apache use timeout with duration==3 hours which sometimes hangs test (for example, when Authentication required but not provided or when broconnection interrupted/died) (Thats why test BrowserTimeOutTest is broken)

2. Hub continues to return error codes with message "Session [...] was terminated due to BROWSER_TIMEOUT" which is confusing and has nothing common with browserTimeout parameter. Currently this error reason is returned by hub to clients (tests) after remote node returns 404 error - 'no such session', See TestSession#closeSessionIfNecessary lines 301, 323, 330
   But behavior is specific - During first request (after session is gone) client gets error "no such session" (proxied by hub) but all subsequent requests return error "browser_timeout":

 someCode();
 // here session lost on node. 
// (for ex., by newCommandTimeout or due --sessionOverride in appium)
 try{
   wd.findElement().getText()  // try to get title:  "no such session"
} catch (WebDriverException e){
  wd.getScreenshot()      // try to make screenshot: "browser timeout"      
}

Of cause wrong reason is not so critical issue but it significantly complicates process of grid environment configuration, logs analysing, investigation of error reasond etc.

Proposed fix for item 1: when initialise proxy httpClient use browserTimeout parameter to instead of using default constant value (3h) for apache and okhttp clients

Proposed fix for item 2:

• use "BROWSER_TIMEOUT" reson only together with browserTimeout parameter (number of seconds a browser session is allowed to hang while a WebDriver command is running (example: driver.get(url)))
• if required add another session termination reason, for example SessionTerminationReason.INVALID_SESSION_ID

[kool79]

Forgot to mention: grid v3.14.0,
Maybe it is the reason for the #5661, #4454, #4508

[kool79]

Forgot to mention: grid v3.14.0,
Maybe it is the reason for the #5661, #4454, #4508

[diemol]

Hi @kool79,

Yes, browserTimeout was not being used in recent versions of Selenium Grid, this has been fixed through these changes and it will be available in the next release.

[diemol]

Hi @kool79,

Yes, browserTimeout was not being used in recent versions of Selenium Grid, this has been fixed through these changes and it will be available in the next release.

[oleksandr-kulychok]

@diemol ,
What about 2nd part of issue :

Hub continues to return error codes with message "Session [...] was terminated due to BROWSER_TIMEOUT" which is confusing and has nothing common with browserTimeout parameter. Currently this error reason is returned by hub to clients (tests) after remote node returns 404 error - 'no such session', See TestSession#closeSessionIfNecessary lines 301, 323, 330

I.e. clients (tests) get wrong exceptions that "session terminated due to browser_timeout" but in fact it is not the case. Due that behavior it is very hard to understand the real rootcause of issue and can be confusing both for test automation engineers and for Selenium support team.

[oleksandr-kulychok]

@diemol ,
What about 2nd part of issue :

Hub continues to return error codes with message "Session [...] was terminated due to BROWSER_TIMEOUT" which is confusing and has nothing common with browserTimeout parameter. Currently this error reason is returned by hub to clients (tests) after remote node returns 404 error - 'no such session', See TestSession#closeSessionIfNecessary lines 301, 323, 330

I.e. clients (tests) get wrong exceptions that "session terminated due to browser_timeout" but in fact it is not the case. Due that behavior it is very hard to understand the real rootcause of issue and can be confusing both for test automation engineers and for Selenium support team.

[diemol]

clients (tests) get wrong exceptions that "session terminated due to browser_timeout" but in fact it is not the case

Why do you say that? Do you have an example where that is not the case? (Also take into account that browserTimeout is broken right now, so this is probably a cascade of wrong exceptions due to that).

[diemol]

clients (tests) get wrong exceptions that "session terminated due to browser_timeout" but in fact it is not the case

Why do you say that? Do you have an example where that is not the case? (Also take into account that browserTimeout is broken right now, so this is probably a cascade of wrong exceptions due to that).