Stale Element Reference Exception. Selenide 5.20.1 и Selenoid

stru4OK · 12.Апрель.2021 12:31:13

Добрый день!

После того как решил перейти с локального запуска браузера на Jenkins на удаленные запуск, используя контейнеризацию (Selenoid) и после обновления Selenide с версии 4.. на 5.20.1 регулярно натыкаюсь на ошибку Stale Element Reference Exception. Ранее подобной проблемы никогда не было. Если попробовать локализовать проблему, то все данные ошибки выпадают на функцию SelenideElement.shouldBe(disappear). Selenide будето отказывается заново искать элемент на обновившейся странице.

Весь стек:
Element should be hidden {By.xpath: //span[contains(text(),‘Configure New AD User’)]//span[contains(text(),’(Active)’)]}
Element: ‘StaleElementReferenceException: stale element reference: element is not attached to the page document</StaleElementReferenceException: stale element reference: element is not attached to the page document>’
Screenshot: ***
Page source: ***
Timeout: 12 s.
at com.codeborne.selenide.impl.WebElementSource.checkCondition(WebElementSource.java:121)
at com.codeborne.selenide.commands.Should.execute(Should.java:30)
at com.codeborne.selenide.commands.Should.execute(Should.java:14)
at com.codeborne.selenide.commands.Commands.execute(Commands.java:155)
at com.codeborne.selenide.impl.SelenideElementProxy.dispatchAndRetry(SelenideElementProxy.java:133)
at com.codeborne.selenide.impl.SelenideElementProxy.invoke(SelenideElementProxy.java:85)
at com.sun.proxy.$Proxy27.shouldBe(Unknown Source)
at Customers.TSystems.Modules.IDaaS.Pages.CreateNewADUser.createNewADUser(CreateNewADUser.java:250)
at Customers.TSystems.Modules.IDaaS.Tests.OrgUnitLeader.creationSingleUserForMoveProcess(OrgUnitLeader.java:227)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at com.tngtech.java.junit.dataprovider.DataProviderFrameworkMethod.invokeExplosively(DataProviderFrameworkMethod.java:119)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)

Возможно кто-то знает в чем проблема и как ее забороть, не костыляя (серии, ловим ошибку данную и заново пытаемся найти эелемент на странице. Как мне казалось, Selenide уже должен решать данную проблему из коробки начиная с версии этак 2, если не еще раньше).

Окружение:

Selenide Version : 5.20.1
Opera : 75.0
Browser Driver Version : Selenoid image selenoid/vnc_opera:75.0
Selenium Version : Selenoid image selenoid/vnc_opera:75.0
OS Version : Selenoid image selenoid/vnc_opera:75.0

Всем спасибо!

Viktor_Yakushenko · 12.Апрель.2021 13:42:20

Наверное раньше проверяло что элемент не существует и not displayed, а теперь только not displayed. Возможно элемент полностью исчезает вместо того чтобы скрыться, соответственно теряется на него ссылка и вы видите эту ошибку.

asolntsev · 13.Апрель.2021 07:41:07

Ну вы даёте! Selenide 5.0.0 вышел уже 2.5 года назад, и вы только сейчас обновляетесь?

Насколько я вижу, ваша ошибка не связана с обновлением селенида.
Давайте разберём:

Element should be hidden {By....}
Element: ‘StaleElementReferenceException: ...’
Timeout: 12 s.

Это значит только одно:

вы ждёте, что элемент пропадёт, но в течение 12 секунд он так и не пропал.
поэтому селенид решил, что надо выкинуть ошибку - отсюда Element should be hidden {By....}.
при формировании сообщения об ошибке селенид попытался добавить детали элемента (тэг, класс, текст) - и вот тут-то элемент и пропал. Отсюда Element: ‘StaleElementReferenceException.

В общем, вам поможет увеличение таймаута.

stru4OK · 13.Апрель.2021 08:49:06

Андрей, благодарю за помощь!
С обновлением на 5 версию все как-то не спешили)
Просто странное совпадение начала периодического появления данной ошибки именно при проверке состояния disappear и переходом на Selenide 5 и Selenoid, поэтому других вариантов и не возникло как связать это именно так)
Selenoid конечно дал приличную задержку (примерно раза в 1.5-2 все стало медленнее проходить) за счет распределенной инфраструктуры (сам Селенойд находится на другой машине, до которой не так просто добраться, но мы это меняем).
И еще странность именно в записываемом видео теста: переход на другую страницу уже состоялся и она благополучно отрисовалась, и вот через 12 сек выпадает эта ошибка.

Андрей, может все же есть какая-то особенность работы Селенида с remoteDriver и исключением типа Stale?
Спасибо!

asolntsev · 13.Апрель.2021 12:38:34

Нет, таких особенностей нет. Во всяком случае, я о них не знаю.

Так бывает, что визуально страница отрисовалась, но внизу в статусной строке по-прежнему горит надпись “Connecting to localhost…”, и браузер всё ещё что-то грузит. И тогда селениум считает, что страница всё ещё грузится.

stru4OK · 13.Апрель.2021 13:30:49

Ясно, значит из-за сетевых задержек происходит подобное. Будем улучшать сетевую инфруструктуру.