tty: implement ReadStream._final to avoid ENOTCONN on .end()

[mcollina]

Fixes: #22814.

Checklist

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

[nodejs-github-bot]

@mcollina build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/906/pipeline

[addaleax]

Is this also a change that came with the libuv TTY changes?

My gut feeling would be that ignoring ENOTCONN during shutdown of any socket would also be a valid fix? Is there ever any benefit from reporting that error back to the user, if it happens while shutting down?

[mcollina]

Is this also a change that came with the libuv TTY changes?

Yes.

My gut feeling would be that ignoring ENOTCONN during shutdown of any socket would also be a valid fix? Is there ever any benefit from reporting that error back to the user, if it happens while shutting down?

I think it's still valid for net.Socket. In this case it is happening because the writable side has never been opened, so it cannot really be shutdown (shutdown only works on writables).

[addaleax]

I know why it’s being emitted… I guess my main issue with this approach is that it adds more special handling for different types of streams, when we’ve been putting some effort into reducing exactly that. Conceptually, the TTY code should not contain any stream specifics, imo…

Alternatively, would it make sense to skip the shutdownSocket call in net.js if stream.writable was false when the stream was created?

[mcollina]

Alternatively, would it make sense to skip the shutdownSocket call in net.js if stream.writable was false when the stream was created?

I'll do that instead. It's more consistent.

[mcollina]

I'm not super confident about this change. Specifically because process.stdin.write() would likely emit an ENOTCONN as well. I think we should error in that case. I'm not sure if we should skip it in this one as well because it is totally harmless. However, calling .end() on what is essentially a readable should not be ok according to the new libuv logic.

[addaleax]

Thanks!

Specifically because process.stdin.write() would likely emit an ENOTCONN as well. I think we should error in that case.

I agree, silently swallowing input data is a different thing.

[mcollina]

I'll see what process.stdin.write() does and open a PR in case.

[Fishrock123]

CI seems to fail? I'm not sure about the exact specifics but it sounds reasonable.

[mcollina]

Let's try CI: https://ci.nodejs.org/job/node-test-pull-request/17251/

[mcollina]

@addaleax handling it within net is not working. I think we should go back to the _final override.

[addaleax]

I think the issue might be that this runs destroy() when it previously didn’t.

I can try it too (later), but maybe undoing this line change and adding if (!this[kShouldShutdown]) return cb(); below works?

[mcollina]

It doesn't because the writable: false parameter that is passed in to the net.Socket constructor does control other behaviors internally, and it does not mean "this is half-open".
If you want to give it a shot, feel free to push here. Otherwise we revert to the _final solution.

[cjihrig]

Unrelated change?

[cjihrig]

"to call" -> "calling"

[addaleax]

I think libuv/libuv@4049879 may have fixed this as well, by making things work again on the libuv side?

[mcollina]

I think so. Have you tested it?

[addaleax]

@mcollina Just checked, and yes, it does fix ./node -e 'process.stdin.end();' when run on a TTY. 🎉

Would prefer to wait for libuv patch (should be soon enough?)

[mcollina]

Let's wait for that.

[addaleax]

I’ve opened a PR with only the test changes here (and attribution to you), so I hope it’s okay to close this. You know what to do if I’m mistaken :)