test: move net reconnect error test to sequential

[arturgvieira-zz]

The usage of common.PORT could cause undesired port collisions when run
in parallel. The following test was moved to sequential.
test-net-reconnect-error.js

Ref: #12376

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

test net

[Trott]

LGTM

[lpinca]

There is a comment on the test

// Hopefully nothing is running on common.PORT

which I think can be removed now. Calls to console.{log,error} can also be removed.
Anyway the cleanup can be done in another PR.

[refack]

[non blocking opinion]
I'm of the opinion that if you're touching a test file, you should normalize it (address @lpinca's comments + add common.mustNotCall instead of all the const N = 20; let client_error_count = 0; let disconnect_count = 0; arithmetic.
But I will not block this over that.

[arturgvieira-zz]

Hi, I've removed the comment, as @lpinca mentioned.

[arturgvieira-zz]

@refack Could you take a look and let me know if this is what you meant? If not could you point me in the right direction? Not sure how to use common.mustNotCall.

[refack]

👍

[refack]

CI: https://ci.nodejs.org/job/node-test-commit/9909/

[arturgvieira-zz]

I checked on the lint errors. Everything should be good to go.

[Trott]

The changes introduced here greatly change the test. Previously, there were 20 attempted connections, now there is only 1. This is not a refactor; this is a change. Should be in a separate PR if at all.

[Trott]

By the way, the change from 20 attempted connections to just 1 seems likely to defeat the purpose of the test, as the test name contains reconnect implying more than 1 connection attempt.

I'm not opposed to refactoring a test that is being moved in general, but I don't know that I would have recommended it here where you already had a bunch of reviews/approvals.

[arturgvieira-zz]

Good point, I will revert it back to the original test.

[refack]

Yep @Trott is right, this should run N times

[arturgvieira-zz]

I have made the requested changes.

[refack]

You could try to add `common.mustCall(..., 20) here and on line 39

[refack]

Good point, I will revert it back to the original test.

I know we're driving you crazy back and forth, sorry...

[arturgvieira-zz]

No worries. I am most interested in getting it right. I don't mind.

[addaleax]

@Trott @refack ping

[refack]

You could use N + 1

[refack]

[suggestion]
I see here an interesting point. Think about this handler...
On the one hand you have the mustCall count that verified each operation is called 21 time.
On the other hand you already have these numbers calculated, so why not check them.

From my perspective it's totally up to you to decide, but thinking about it IMHO is the important part.

[refack]

Stress on freeBSD (100 x all sequential): https://ci.nodejs.org/job/node-stress-single-test/nodes=freebsd10-64/1230/

[arturgvieira-zz]

@refack I made the first changes you requested and used N + 1, but not sure what would be the desired change on the second request entry, the one about the 'exit' handler. If you could clarify. Thanks

[refack]

@refack I made the first changes you requested and used N + 1, but not sure what would be the desired change on the second request entry, the one about the 'exit' handler. If you could clarify. Thanks

👍
About the second part, I just said "think about it". You can keep it, or you can remove it, I don't have a strong opinion either way.
IMHO you should decide! And I'd be happy to hear your rationale.

P.S. Stress test seems to pass.

[Trott]

LGTM if CI is green. Thanks for sticking with it!

[arturgvieira-zz]

@refack I think that since those variables are used in the test, that we should track their input and output values. As a way to make certain that the test framing stays together, making sure that their values are known helps to understand the test, and have expectations as to results.

[refack]

@refack I think that since those variables are used in the test, that we should track their input and output values. As a way to make certain that the test framing stays together, making sure that their values are known helps to understand the test, and have expectations as to results.

Sounds like a good reason to me. Thank you for taking the time to indulge me 👍

[refack]

CI: https://ci.nodejs.org/job/node-test-commit/10039/
If green I'll land.

[refack]

landed in c60a7fa

[refack]

Post land CI: https://ci.nodejs.org/job/node-test-commit/10041/