Тоже самое, то проверяет еще Доступен ли элемент

Значит, стоит дождаться сперва загрузки страницы, потом перенайти элемент, раз айди меняется

Так и делаю. Создал свой Ассерт , жду когда появится нужный tittle страницы

В изначальном примере вызывается он, а ожидалка стоит в FindElement()
findElementClickable вызывает внутри себя findElement с ожидалкой?

Нет, я не тот скинул . Вот этот метод

В Вашем приложении, тайтл страницы -- это 100% маркер того, что страница загрузилась и не будет меняться?

Ну в основном да. Попапов очень мало , в основном новое действие , новая страница

Вот сюда, возможно, имеет смысл заглянуть:
https://m.habr.com/ru/post/111649/

Я бы ещё на фронт добавил какой-то индикатор окончания отрисовки содержимого таблицы. Типа спиннера или затемнения. И на него бы ориентировался.

У меня ошибка не в том , что элемент не нашелся, а в том что он поменял свой ид. Т.е при при клике на кнопку, у меня возвращается пред. таблица и перезагружается . Но селениум нашел старый элмент в DOM , а на момент клика ид уже другой

Значит надо в том действии, из-за которого появилась новая таблица, ждать рабочего состояния таблицы.

Можно сговнокодить и добавить бексонечный цикл с маркером и отслеживать исключение StaleElementException , но возможен бесконечный цикл

Эм , это все на другой странице происходит. Что бы попасть на страницу с таблицей нужно link нажать.  Возможно в локалсторадже состояние таблицы хранится из-за этого это все

Тогда что-то не сходится. Смотри, ты в тесте вызываешь ClickLinkDetails(), успешно находишь элемент, но к моменту клика он пропадает. Варианта два.
1) Элемент нашёлся на старой странице, а к моменту клика уже есть новая. В этом случае тебе надо корректное ожидать загрузки новой таблицы.
2) элемент нашёлся в верной таблице, но из-за механизма работы таблицы элемент успел исчезнуть. В этом случае тебе надо ждать, когда когда таблица добавила все элементы и больше их не меняет.

ок спс подебажу  посмотрю .

@Cfc0801 Зависит от реализации таблицы. Помню, на одном из проектов делали полностью кастомный грид, где каждый индивидуальный row - это отдельный компонент. В реакте допустим при таком раскладе вся страница никогда не будет перерисовываться (разве что по рефрешу).  Изменение значения отрисовывает только заафекченную часть. Если это значение влияет на данные во всей таблице (аля пересчет по каким-то формулам или банальная фильтрация), то естественно грид начнет обновляться. Ну и поэтому смотреть на тайтл нет никакого смысла. Эффективней всего будет понаблюдать в дереве, какая часть начинает меняться при обновлении значения (по тем же id в вашем случае это сразу будет заметно), и дальше повесить якорь рутовый на элемент, относительно которого идут изменения. Но на самом деле, это тоже может ничего не дать в случае существования row/cell - как отдельного компонента. Привязавшись к руту, вы можете схватить снепшот еще до того, как пройдет каскадное обновление всех вложенных компонентов. Так что наверное лучше в таком случае пойти от обратного - взять самый вложенный (по возможности) компонент, например - строка или ячейка. Но проверять на обычный visibility тоже нет смысла. Есть разные варианты: смотреть за размерностью, фактом изменения значений, атрибутов и т.п. Каждый случай может быть уникальным. К тому же, "высокопроизводительные" таблицы (на трейд платформах допустим) могут успеть несколько раз обновить значение в ячейке еще до того, как ваш запрос долетит через пол мира по сети через условный селениум грид на браузер. Так что it depends.

сейчас есть совет "возьми Playwright" 😉

Я для борьбы с неустойчивостями дерева и нестабильностями робота в своем фреймворке обернул все вызовы в конечный автомат, который грамотно обрабатывает все сбои и следит за таймаутами. Предполагаю, что Selenide работает по тому же принципу.

Есть даже термин такой - 'селениды'