net: emit 'close' after 'end'

[lpinca]

Currently the writable side of the socket is closed as soon as UV_EOF
is read regardless of the state of the socket. This allows the handle
to be closed before 'end' is emitted and thus 'close' can be
emitted before 'end' if the socket is paused.

This commit prevents the handle from being closed until 'end' is
emitted ensuring the correct order of events.

Fixes: #19166

Checklist

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

[lpinca]

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

[lpinca]

This is potentially semver-major as the 'close' event is no longer emitted if UV_EOF is read and the socket is paused.

[addaleax]

This aligns behavior with other Duplex streams, right? I like that. 👍

Will take a closer look tomorrow

[lpinca]

Yes, at least it aims to do that.

[mcollina]

I think this is semver-major.

[mcollina]

LGTM

[lpinca]

CI: https://ci.nodejs.org/job/node-test-pull-request/13601/
Windows failures are related, I'll investigate.

[lpinca]

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

[addaleax]

CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1330/

[mcollina]

@lpinca can you please check that we follow this pattern also in HTTP, HTTP2, fs, etc?

Also, pump should keep working.

[lpinca]

can you please check that we follow this pattern also in HTTP, HTTP2, fs, etc?

This is not trivial, it seems to be the case for HTTP but not fs, the 'close' event is emitted as soon as the fd is closed. This is properly documented though. Not sure about HTTP2 I'm not familiar enough with the codebase.

pump is tested by CITGM right? If so it seems this change does not break it.

[mcollina]

@lpinca pump is not in citgm atm.

[addaleax]

For HTTP/2, allowHalfOpen is always true, so I don’t think we have to worry about that.

[lpinca]

@mcollina ok, I'll

1. Run pump tests locally.
2. Open a PR in GITGM to add it.

[lpinca]

pump tests pass locally, also it either calls destroy() or wait for the 'close' event (or end-of-stream callback). When destroy() is called the 'close' event can still be emitted before 'end'. This patch does not handle that case.

I'm a bit hesitant on adding it to CITGM as it seems to be only tested with fs and default stream classes and there is already pumpify for that in CITGM.

[lpinca]

cc: @mafintosh

[lpinca]

I would like to land this. It already has 3 TSC approvals but it would be nice to have more opinions.
Ping @nodejs/collaborators @nodejs/streams.

CI: https://ci.nodejs.org/job/node-test-pull-request/13738/
CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1337/

[benjamingr]

Definitely semver-major, changes lgtm

[lpinca]

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

[lpinca]

Landed in 0ac4ef9...9b7a691.

[brettkiefer]

@lpinca On redis/ioredis#633 I'm seeing that the socket is not in a paused state (that is, its isPaused() returns false) but does have a writable of true when we hit onReadableStreamEnd, causing the close event to never fire and resulting in a stuck IORedis cluster client. Is that an intentional result of this change, or would you generally still expect to see a 'close' event emitted for a non-paused socket?

If the answer is that this is not an intentional new behavior, I'll try to boil it down to more minimal repro case (one that doesn't involve spinning up a Redis cluster).

[lpinca]

If the socket is still writable it's expected, 'close' should not be emitted if the socket is writable.

[brettkiefer]

@lpinca Ok, thanks! It looks like what is happening here is that when we connect with a timeout that fires off an end on the connecting socket and then delay the socket connection so that afterConnect fires after end, we get the ordering:

Socket.end from client code on timeout (calls down to stream.Duplex.prototype.end, setting this.writable to false and this._writableState.ending to true)

Socket.afterConnect(sets this.writable to true when we connect without error)

Socket.onReadableStreamEnd (calls this.end)

Socket.end (calls stream.Duplex.prototype.end)

Writable.prototype.end (does NOT call endWritable because this._writableState.ending is already true from the previous call to socket.end, so this.writable stays true)

socket.maybeDestroy (does not call socket.destroy because socket.writable is true, so this.destroy is never called and close is never emitted)

So that causes the socket to never call Socket.destroy, where before this change it would have called destroySoon immediately, masking the bug (at least it looks to me like a bug) with this.writable being set to true by afterConnect even though the rest of the state indicates that it should not be.

Does that make sense to you? It may be that I have an incorrect expectation that calling Socket.end on a socket before it finishes connecting will eventually result in the socket emitting close, but that seems to me to be the correct behavior. I realize that this is really not a bug with your change, but the interaction, resulting in close never being called in this case, seems like it might be worth attention -- I just thought I'd run it by you first since you touched it last and probably have the best sense for the expected behavior.

[lpinca]

@brettkiefer yes it makes sense, this is an interesting race condition. afterConnect() should not blindly override the value of this.writable imho.

A dirty workaround would be to call socket.destroy() instead of socket.end() on timeout but I agree that this is a bug and should be fixed.

[brettkiefer]

@lpinca Thanks. that sounds like a good idea. I'll see what IORedis might accept as a workaround and get an issue submitted against Node.js tomorrow (unless you think you can give better context, in which case please feel free) and link it here.

I don't immediately see any internal state on the socket that looks appropriate for switching behavior in afterConnect (although I guess it peeks at the _writableState in a couple of places) so I'm not sure what an appropriate PR would be, but at least it seems like it's worth surfacing the issue.

[lpinca]

Here is a test case for the issue you are describing:

const net = require('net');

const server = net.createServer();

server.listen(() => {
  const socket = net.createConnection(server.address().port);

  socket.on('connect', () => console.log('connect'));
  socket.on('end', () => console.log('end'));
  socket.on('close', () => console.log('close'));
  socket.end();
});

No 'close' event is emitted in this case, but I think it should.