GeezerVison

Review requested:

• @nodejs/streams

Missing test. Also I would like to understand how this can fix that issue. This seems wrong to me.

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

Missing test. Also I would like to understand how this can fix that issue. This seems wrong to me.

Obtained by blindly comparing NODE_DEBUG outputs of node 12 vs node-master - they remain remarkably similar despite the fact that the code base has been throughly refactored

Missing test. Also I would like to understand how this can fix that issue. This seems wrong to me.

Obtained by blindly comparing NODE_DEBUG outputs of node 12 vs node-master - they remain remarkably similar despite the fact that the code base has been throughly refactored

Maybe it just reproduces the bug that made it working 😄

I feel there is a more fundamental issue here and suspect that this might just hide it.

I feel there is a more fundamental issue here and suspect that this might just hide it.

I spent two hours yesterday evening and couldn't fully understand it. My theory is that returning false from _write pauses the stream and gives the 'end' chance to get delivered. Otherwise everything remains stuck in an endless loop with the 'end' waiting in a nextTick handler.

I mean part of the problem here is that Readable.push(null) does not Writable.end() the writable side of the Transform.

We could fix that by:

if (this.readableEnded) {
  this.end()
}

inside the transform callback but that would cause a write after end error as I mentioned here.

Just to be clear that I don't mind landing this PR to fix behavior regression (it has some perf regression for sync case) but I don't think it actually solves the fundamental problem here.

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

Sorry if naive question. When this can be released?

This can land in another 40 hours. Then it'll ship in the next v15 in the next week or so. It needs to sit in a current release before being bumped to LTS for 2 weeks. My best guess is at least a month, if not a month and a half.

Given that it seems a pretty urgent regression, we might be ok in short-circuiting this. What do @nodejs/tsc @nodejs/releasers @nodejs/lts think?

@mcollina Do you know when the regression went out in the LTS releases? I'm open to short-circuiting the wait time if it's a recent regression and this PR has sign off from @nodejs/streams.

@richardlau I think this has been there for most of v14 current cycle - not recent at all. It's not in v12.

Just checked. This bug appeared in v14.1.0. Previous versions not affected.

@targos has been preparing a 15.x release for tomorrow, so if this should be urgently fixed perhaps fast tracking into tomorrow's release is an option? We pencilled in a 14.x release for this month but AFAIK haven't settled on an exact date but if this does go out in tomorrow's 15.x release it'll probably make it into the next 14.x release without needing to short circuit LTS wait times.

Then let's fast-track this

cc @nodejs/tsc for awareness

@Trott , @lpinca was this supposed to be included? I am sorry if it was up to me to backport it? What is the usual process when a PR needs backporting?

I think releasers will cherry-pick and leave a note here if it doesn't land cleanly. @nodejs/releasers Should a backport to 14.x be opened at this time? Or hold off?

@mmomtchev If you're confident that this will not be able to be cherry-picked to the v14.x-staging branch and that it should be included, you can get open a backport release by following the instructions at https://github.com/nodejs/node/blob/master/doc/guides/backporting-to-release-lines.md.

May be reopen #35926 until fix in v14 (LTS)? Bug is serious, IMO.

I am confident, the file I modified does not exist on v14.x

@puzrin @Trott I submitted a PR to v14.x-staging with a backport of this change