When using expect().not for matcher negation, the isNot may not be processed correctly.

• In short, when using .not, we fail early on the first failure condition, whereas without it, we wait until we eventually succeed.
• This makes a given scenario be true for both is non negated and the negated version, which should be technically impossible

For example:
If we have a wait of 10 sec and the text becomes 'GOOD' at 5 sec
Then

expect($('myElement')).toHaveText('GOOD') 

will pass after waiting 5 sec

Also, with today's bug, if you do

expect(element).not.toHaveText('GOOD')

It will also pass because, on the first attempt, it is effectively false.

Having both above conditions pass for the same scenario does not make sense.
By waiting, we ensure we have the 'real' fetched value and thereby negate that same 'reality.'

The test case below on the main branch proves the bug

The waitUntil function must be reviewed to not fast-forward the process when isNot=true

⚠️ If the wait time is too long now because of the fix and it's not progressing fast enough for you, reducing the wait time with { wait: 1000} will resolve the issue.