Missing Reports in Nightwatch with GGR + Selenoid
Recently I noticed that in some cases, when running Nightwatch with GGR and Selenoid, some reports were missing. The test would reach the end, but at the reporting moment, the last one (sometimes the last 2 or 3) were not in the reports.
My investigation
I started my investigation by checking if unresolved promises during the tests could cause the process to be lost and not report, but soon I discovered that this was not the case.
I also investigated possible session-ending requests before the report arrived, but I found out that Nightwatch handles this well with its command queue — even if a promise is not awaited, the next command will only execute after the previous one finishes, so that wasn’t a problem either.
I tried forcing long calls in the after of each test, and even then Nightwatch handled it fine.
So I decided to go deeper and forked the repository, figured out how it worked, and started validating hypotheses until I finally found the issue.
I’ll make a summary here, but you can read it in full on the discussion:
👉 Nightwatch Issue #4416
What’s happening under the hood
The process of running tests in parallel creates several promises. Each promise is a child process, and inside each child process, during the end of the test suite, data is transmitted to the parent process through IPC messages. Then the test-end event is emitted, and the process ends.
The parent process, after all promises are resolved, moves on to the report stage.
The problem is that IPC messages don’t control delivery, only sending. This creates a race condition because:
- The child process sends the IPC message
- The child process emits the test-end event
- All promises resolved → report step
What rarely happens is:
- IPC message with test data is sent
- Test-end event is emitted
- Parent process moves to the report step since all promises are done
- Report step collects the available data
- Report is generated
- IPC message content arrives afterward
Propose solution
Since there is no way to wait for the message to be delivered, I proposed a solution where the child process would send the message and wait for a response from the parent process confirming that the message was received.
Top comments (0)