Fix waitUntil not working with async/await.

[chikara1608]

Fixes: #3511.

waitUntil command was getting prematurely resolved when used with async/await due to which the execution of the callback passed to the waitUntil command was getting overlapped with the Nightwatch commands following the waitUntil command.

This was happening because inside the command queue tree, whenever child nodes are resolved, the parent node is also automatically called to be resolved which was causing pre mature resolution of waitUntil.

[CLAassistant]

All committers have signed the CLA.

[garg3133]

We shouldn't ideally hardcode a command's name over here, but instead have some logic inside this.otherChildNodesInProgress() method to decide whether the command has finished completely or there are still some child nodes that can potentially be added to the command, again without hardcoding the command name.

[garg3133]

Also, if the waitUntil command fails, we should ideally abort the test execution and display the error instead of continuing the test execution.

await browser.waitUntil().pause() would do just that (if the waitUntil command fails, it won't execute the pause() command.

But if we write it as:

await browser.waitUntil();
browser.pause();

it would execute the pause() command even after the waitUntil command fails.

[garg3133]

What we can do here is (for the first comment) declare a flag in the command file itself (as you suggested earlier) using a get method and then use that flag to decide whether to resolve the parent node as well with the same result or not.

This can be done by returning the flag value from getCommandOptions() method in lib/api/_loaders/_command-loader.js file, which will then be available in node.options in the asynctree.js file and can be used there.

And instead of using this.otherChildNodesInProgress() for this purpose, we can create a new this.resolveParentNodeWithResult() method and put the logic for deciding this in there.

[garg3133]

And then maybe we can iteratively do this for all the commands to deprecate this logic altogether (as this logic I think is only relevant to the client-commands which then call some protocol command to do the work, as we're slowly deprecating such commands).

I think a good way to do this would be to bypass this logic for a few commands in every release to ensure that we don't end up breaking anything (and if we get complain for some commands, we can just revert the commit from that release). And once we've bypassed this logic for all the commands, we can safely remove this.

For the note, according to my understanding, this logic was used for commands that call other commands to do the actual work, and when those "child-commands" returned a result, the parent command (which is the original command that the user used) should also be resolved with the same result, so we resolve the parent node as well with the same result as the child node using this logic.

But we don't need to do any of this in the current PR, this PR is only for waitUntil command.

[github-actions]

Status

• ❌ No modified files found in the types directory.
  Please make sure to include types for any changes you have made. Thank you!.

[garg3133]

@AutomatedTester This PR is ready to be merged.

There are a few issues related to waitUntil command still left, for which we might need to file separate GitHub issues:

• Fix waitUntil not working with async/await. #4123 (comment)
• waitUntil not working with async/await #3511 (comment)
• waitUntil not working with async/await #3511 (comment) (yet to read it through)

[garg3133]

There are a few issues related to waitUntil command still left, for which we might need to file separate GitHub issues:

• Fix waitUntil not working with async/await. #4123 (comment)
• waitUntil not working with async/await #3511 (comment)
• waitUntil not working with async/await #3511 (comment) (yet to read it through)

Opened #4157 and #4158 for the first two issues.

For the third issue, it must have something to do with the side effects of the queuing system arising from the waitUntil callback getting overlapped with the other commands, due to which the result of some other command must be getting passed to the getText command (maybe the getText command became a parent to some other command and then got resolved prematurely with the result of a child command).

It won't be possible (or easy) to investigate the issue without the verbose logs so we can leave it for now. Anyways, as the user said, it gets resolved after removing the waitUntil command, so it must be happening due to the callback overlapping only, which is resolved now.

Related Discord thread for the third issue: https://discord.com/channels/618399631038218240/1085703830685093918/1085703830685093918