[MGNLTEST-204] VaadinWrapper::vaadinIsDone should "end gracefully" Created: 29/Mar/22  Updated: 01/Apr/22  Resolved: 01/Apr/22

Status: Closed
Project: Magnolia Test Framework
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Christoph Meier Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MGNLTEST-198 ContentApp#selectRowByPath PO can sel... Accepted
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)

 Description   

We wrap most (all?) of the WebElement(s) with VaadinWrapper.
When finding elements, we call #waitUntilVaadinIsDone.
Since Vaadin is using async requests all the time, this seems to make sense in many cases -

BUT we also have found cases, where Vaadin is never done - then endong up with a timeout-exceptions
For instance this is the root-cause for the issue described in MGNLTEST-198.

The JS-code of vaadinIsDone should stop at some point.
Since we cannot really be sure whether Vaadin adds now async calls "constantly".
Maybe we can restrict it to a max. number of "clients[client].isActive()" (see VaadinWebElementWrapper).
When such max.number is reached - we should:

  • log that we stopped "earlier"
  • but return true in order to give selenium a chance to proceed


 Comments   
Comment by Christoph Meier [ 01/Apr/22 ]

Using now the story MGNLTEST-208 which is more detailled with better refined sub-tasks

Generated at Mon Feb 12 07:46:35 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.