test: add a test for "tls.Socket" with "StreamWrap" and "allowHalfOpen"

[oyyd]

A tls client socket using StreamWrap with allowHalfOpen option might hang instead of exiting automatically because the 'drain' event may not be emitted. This commit corrects it by making StreamWrap try doShutdown in finishWrite.

Before this commit, running the following test will make processes hang.

This test ensures that a tls client socket using StreamWrap with allowHalfOpen option won't hang.

Refs: #23654

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

[addaleax]

Once again, nice work!

[addaleax]

@oyyd Actually … do you know why there are a write request and a shutdown request simultaneously in that code? In net.js, shutdownSocket() is only triggered in _final(); and I thought that always happened after all writes are finished… is that wrong?

[oyyd]

@addaleax this.finishWrite() and this.finishShutdown() inside of doClose() are likely to be no-ops. But in theory, there are some places doing handle.close() outside of _final(), such as this one:

node/lib/net.js

Line 1236 in 6223236

handle.close();

As handle.close() trigger doClose() and some of them are outside of _final(), it looks possible that this.finishWrite() and this.finishShutdown() would take effect.

But, again, handle.close() outside of _final() never get called when wrapping net.Socket in StreamWrap. We don't use StreamWrap for server sockets and StreamWrap is even not a public API in our docs. At least, I tried hard but failed to create a possible scenario and removing them didn't break any tests on my Mac.

Maybe some of our old code used them somehow, but IDK. The usage of StreamWrap in http2 is similar.

If you are suggesting removing them, I would agree with that.

[addaleax]

@oyyd As you say, the line you’re pointing to is for server sockets, so I don’t think that’s an issue…

The thing is, generally there should only be 1 ShutdownWrap or 1 WriteWrap be active for a certain stream, ever… it’s okay that doClose() can be called at any time, but if I understand correctly, this PR fixes the situation when there is a ShutdownWrap and a WriteWrap? And I’m wondering why that situation occurrs in the first place…

[oyyd]

generally there should only be 1 ShutdownWrap or 1 WriteWrap be active for a certain stream

I agree.

this PR fixes the situation when there is a ShutdownWrap and a WriteWrap?

I'm not totally sure but I guess it doesn't, or my intention is different. My original intention is that I noticed that some stream won't emit drain(or they emit earlier than we bind to drain) so that we won't call this.stream.end() correctly:

node/lib/internal/wrap_js_stream.js

Lines 118 to 119 in 6223236

	if (this[kCurrentWriteRequest] !== null)
	return this.once('drain', () => this.doShutdown(req));

But it works well because when a ReadableStream ends, they call end() on WritableStream, except that this.allowHalfOpen is true. And calling end() later than expected might cause other issues.

For those writing operations don't emit drain, I try to call kDoShutdown after WriteReq so that the streams will end correctly.

[danbev]

CI: https://ci.nodejs.org/job/node-test-pull-request/18195/

[oyyd]

Test failed: parallel/test-https-host-headers

log

test https server listening on port 41235
/home/iojs/build/workspace/node-test-commit-arm/nodes/centos7-arm64-gcc6/test/parallel/test-https-host-headers.js:31
throw er;
^

Error: 4395995780336:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../deps/openssl/openssl/ssl/record/ssl3_record.c:469:

[oyyd]

parallel/test-https-host-headers seems to be flaky as it could also fail before this commit and the error logs are just like other flaky tls tests (like: #23913)

[addaleax]

@oyyd Not to spoil this for you, but … the test file here seems to be passing on Node 11.0.0 (but not 10.13.0) – bisecting actually points to your #23654 as the fix :)

[oyyd]

@addaleax Oops, I guess I was taking Node 10.x as my "control group" by mistake.. But I still have some doubt about the reason. Let me dig into this a bit.

[oyyd]

Not to spoil this for you, but … the test file here seems to be passing on Node 11.0.0 (but not 10.13.0) – bisecting actually points to your #23654 as the fix :)

Yes. Therefore I prefer not to modify the code if we couldn't find clear goodness it could bring.

But I think it's fine to keep the test for #23654. I have modified the title and description of this PR.

BTW, another place that is confusing to me is that if we don't call tlsSocket.end(), i.e. comment this line:

https://github.com/nodejs/node/blob/9fa47cf6d3b059b1ac612b5f8ec4cd96ba6d4ad2/test/parallel/test-tls-net-socket-keepalive.js#L25

Then the sockets won't hang anymore on Node 10.13.0. This needs more investigation but we could discuss it elsewhere.

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/18350/

[addaleax]

Still very much LGTM :)

[addaleax]

Landed in aa82a21, thanks for the PR! 🎉