Custom implementation of Inspect in Wallaby.Element creates heisenbugs
rrosztoczy opened this issue · 5 comments
Issue
I am not sure this is an issue, but more of a comment I had after spending a lot of unnecessary time investigating what turned out to be a heisenbug.
You have a custom implementation of Inspect for Wallaby.Element that introduces a side effect by calling out to the webdriver client. What this means is that anytime a developer tries to inspect an element after it has been changed (say, inside of the click function as in my case) they will inadvertently create a stale reference exception. Not from the e2e test flow they are inspecting, but from the act of inspecting itself.
Unfortunately, this exception tends to be a common response when working with webdrivers (from my perspective it should be an expected response but alas...) and in my case specifically, it was the exact type of error I was trying to investigate. Imagine my surprise when I see an {:ok, _} tuple filtering all the way back through the library and into the Element.click function, but when I inspect the element that is returned I see the exact exception that the code path is telling me did not occur. I did not think to look for an override of Inspect until I stumbled across it.
I am not sure how valuable the text formatting is to users, and whether that is more important than overriding the implementation of Inspect with one that introduces a particularly interesting side effect, but I figured I would let you know it happened.
It is not a duplicate issue, but the try/rescue solution suggested would resolve both issues.
Can you explain the difference between the behavior you've observed and the issue I linked?
My issue did not occur from running tests or due to a killed session, but rather from inspecting an element in the Wallaby Wallaby.Element module after an event that changed the dom -> in my case, it was trying to inspect the element returned inside of the Browser.click/2 function.
The test did not fail, instead the click executed successfully, so the code ran through the success path and returned the element. However, when I tried to inspect that element in line 89 of Wallaby.Element, the inspect returned a stale reference error - impossible given that I was inspecting the success path. This occurred because of the attribute call to the webdriver inside of the inspect.
The implementation is problematic in more ways than one and the suggested changes are an improvement.
Ahh, I see now. I should clarify issue #548
As I see it, the issue is if something goes wrong during the side effect executed by calling inspect on an Element, the call to inspect should not fail.
In your case, the call to inspect fails because it raises a stale reference exception during the call.