Fix for issue #2713

[chris-codaio]

• Eagerly set the process exitcode in case the write callback isn't executed before the process terminates.
• Remove the extraneous call to done() at the bottom of the function.
• Cleanup the draining reduction and value check in done into separate lines for easier reading.

[jsf-clabot]

All committers have signed the CLA.

[coveralls]

Coverage remained the same at 88.188% when pulling ef2b5e5 on chrisleck:issue/2713 into a2fc76c on mochajs:master.

[Munter]

Is is possible to consistently recreate the issue from #2713 ? If it is, a test case to guard against regresssions would be helpful

[chris-codaio]

I wasn't able to create a standalone test case. Seems timing dependent in node.

[chris-codaio]

Ping for action?

[chris-codaio]

Can we get this PR approved or follow up with review comments?

[chris-codaio]

Ping-a-ling-a-ping-ping

[chris-codaio]

@Munter Sorry for the direct ping. Mind taking another look?

[Munter]

I understand the value of eagerly setting the exitCode with process.exitCode = .... That part seems good to me.

Without tests I'm not sure what the bigger consequences are of removing the done() call at the end

[chris-codaio]

@Munter What's your concern about the done() call at the end? The existing code is pretty clearly unbalanced - each stream instance adds one to draining and each callback removes one. The done() call at the end causes draining to reach 0 before the second stream has called done(), thereby defeating the purpose of this ref-counting mechanism.

An alternative to my approach for making the system balanced is to initialize draining to 1 such that the call to done() at the end of the method is the third callback needed to get draining down to 0. That may be even safer than my approach and I'm happy to make that change if you'd like. Please advise.

[chris-codaio]

@Munter waiting for your response.

[chris-codaio]

@Munter ping for response.

[ScottFreeCode]

Why not just address the setting of process.exitCode and the correctness or incorrectness of the draining logic (involving the done() call) in separate issues/PRs?

(Actually, we should double-check whether the draining logic's done calls have come up before -- we might already have an issue about investigating it. But in any case, there's benefit to setting process.exitCode once we know how we're going to exit even if we don't touch the draining logic, so...)

[chris-codaio]

@ScottFreeCode That sounds reasonable. I'll send out a new PR shortly.

[dasilvacontin]

whether the draining logic's done calls have come up before

@ScottFreeCode can you elaborate?

The logic rewrite looks good to me.

Regarding that extraneous done call, take a look at the old condition:

if (!(draining--)) {

The condition will be true when the value of draining is 0 before hitting the if. draining-- returns then current value of the variable and then it decrements the variable.

So the logic was correct. But laid out in a very confusing way.

[ScottFreeCode]

Thanks, that's what I remember discussing (or at least looking at) before... The parentheses make it particularly confusing because normally they're used to force things to happen in a certain order, but in this case we've got a rare instance of C/C++-style variable-value separation that leaked into JS and even the parentheses don't affect that. (I guess they ensure that the decrement is applied to the variable and not to the result of the negation?)

So it's equivalent to:

if (!drain) {
  ...exit...
}
drain -= 1

...and not to:

drain -= 1
if (!drain) {
  ...exit...
}

And so we don't need to change it for correctness... But we really ought to change it for clarity.

In fact, I would love to see an ESLint rule against postincrement/postdecrement operators. (Wouldn't even say no to such a rule against preincrement/predecrement as well, considering command-query separation ought to be respected if you're going to be using mutable variables in the first place...)

[boneskull]

This was fixed via #2820