Zero coverage reported after SIGKILL

[mayant15]

I have a script that blocks the event loop and is run with a timeout:

// in loop.js
while(true) {}

$ timeout -s KILL 2s node loop.js

nyc reports zero coverage when the node process is killed, when in this case it should be 100%.

$ npx nyc timeout -s KILL 2s node loop.js

----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files |       0 |        0 |       0 |       0 |
----------|---------|----------|---------|---------|-------------------

Also noticed that if sending a SIGTERM as timeout does by default, the node process doesn't terminate.

$ timeout 2s node loop.js # this terminates
$ npx nyc timeout 2s node loop.js # this doesn't terminate

Version Info

• nyc 17.1.0
• node 22.12.0
• npx 11.2.0

[jdmarshall]

I have a script that blocks the event loop and is run with a timeout:

// in loop.js
while(true) {}

You understand why this can never work?

[mayant15]

Does nyc attach a listener to SIGTERM on the child process? If not, Node.js's default handler should terminate the process, regardless of what the event loop is doing. This terminates:

timeout 2s node loop.js

[jdmarshall]

You cannot receive a signal in Nodejs while the event loop is unresponsive.

The event generated by the signal will be processed only the next time the event loop becomes available. If the application is hung, there is no graceful shutdown. NYC would have to run multiple processes and collect incremental data in order to do what you ask.

I'm saying this as an NYC user. I don't know if I've even landed a single bug fix.

While it could be possible for nyc to do this, detecting a hung process is really a better feature for your testing framework, not nyc. Because it's a code failure, not a coverage failure. If the framework can fail gracefully on its own timeouts, then so can nyc.

But really hung tests should probably be a conversation with your peers. I appreciate that a better error message definitely helps facilitate that sort of conversation. But NodeJS makes that into advanced functionality. And Node is really not appropriate for CPU tasks that can run 'forever'. You may want to break up the logjams in your code.

[mayant15]

Hi, thanks for the response! I think I see now where the problem is. I'll try to clarify a bit.

You cannot receive a signal in Nodejs while the event loop is unresponsive.

You cannot execute the attached JS listener for a signal while the event loop is unresponsive. For SIGTERM and SIGKILL, if there are no JS listeners attached, Node.js just terminates the process even if the event loop is unresponsive.

With that I can clarify the two questions I had.

SIGKILL

Node.js does not support JS listeners for SIGKILL. As a result, as you rightly point out, the child process would not follow usual graceful termination and to account for that, nyc would have to collect incremental data.

The question: Is there an option in nyc to collect incremental data? Or maybe is there a flush() function I can call (say every 1000 iterations of my while loop) to record incremental data?

SIGTERM

If the framework can fail gracefully on its own timeouts, then so can nyc.

Yes, I would expect that to be the case. But that does not happen here. The framework does terminate when it receives a SIGTERM (since it does not attach a JS listener and relies on Node.js's default behaviour), but not when run under nyc.

The question: Is the difference in behaviour when running with and without nyc expected because nyc does use a JS listener for SIGTERM in the child process? Or is there a workaround?

More Context

In the real codebase I don't have a while(true){} in JS. I'm writing a Node add-on that calls a Rust library which has a loop deep in it (that I cannot break up). Inside this loop I call JS functions from Rust. This has the same effect as blocking the event loop with a loop in JS. I'm interested in the coverage of these JS functions, the ones called from Rust.

Having incremental coverage data would make it really simple to do this.