Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node v15.6.0 changes the behavior of .end on zlib.DeflateRaw #37027

Closed
Aaron1011 opened this issue Jan 22, 2021 · 10 comments
Closed

Node v15.6.0 changes the behavior of .end on zlib.DeflateRaw #37027

Aaron1011 opened this issue Jan 22, 2021 · 10 comments
Labels
stream Issues and PRs related to the stream subsystem. zlib Issues and PRs related to the zlib subsystem.

Comments

@Aaron1011
Copy link

  • Version: v15.6.0
  • Platform: Linux ArchLaptop 5.10.9-arch1-1 deps: update openssl to 1.0.1j #1 SMP PREEMPT Tue, 19 Jan 2021 22:06:06 +0000 x86_64 GNU/Linux
  • Subsystem: zlib

What steps will reproduce the bug?

The following code:

const {DeflateRaw} = require('zlib');

class MyStream extends DeflateRaw {
    constructor(options) {
        super(options);
    }

    write(chunk, enc, cb) {
        console.log("Write: " + chunk + " " + enc + " " + cb);
    }
}

console.log("Running");
const s = new MyStream();
s.end(Buffer.from('hello world'));

produces the following output on Node v15.6.0:

Running

On Node v15.5.0 and below, it produces the output:

Running
Write: hello world undefined undefined

How often does it reproduce? Is there a required condition?

This reproduces 100% of the time

What is the expected behavior?

Calling end should call the overridden write method with the supplied data, as in Node v15.5.0 and below.

What do you see instead?

The overridden write method is not called.

Additional information

This leads to node-archiver producing invalid ZIP files: archiverjs/node-archiver#491

PR #36618 seems like it might be related

@Trott
Copy link
Member

Trott commented Jan 22, 2021

@nodejs/zlib @nodejs/streams

@lpinca
Copy link
Member

lpinca commented Jan 23, 2021

The issue seems to be caused by a4fce32. Reverting it makes the example work as expected.

@targos targos added stream Issues and PRs related to the stream subsystem. zlib Issues and PRs related to the zlib subsystem. labels Jan 23, 2021
@mcollina
Copy link
Member

@ronag wdyt? I have a feeling we should be reverting a4fce32 and add a unit test.

@lpinca
Copy link
Member

lpinca commented Jan 23, 2021

I think a4fce32 is fine. The documentation does not mention that writable.end() calls writable.write() and writable._write() is still called as expected.

I would only revert on v15.x and mark #36817 as semver-major.

@pgrzesik
Copy link
Contributor

Hello 👋 To clarify - @lpinca - does that mean that the original PR (#36817) that caused issues for some packages depending on undocumented behavior will be merged to the next major version? Thanks in advance 🙇

@mcollina
Copy link
Member

Hello 👋 To clarify - @lpinca - does that mean that the original PR (#36817) that caused issues for some packages depending on undocumented behavior will be merged to the next major version? Thanks in advance 🙇

Yes, we do not plan to revert on master, only on v15.

@pgrzesik
Copy link
Contributor

Thanks for clarification @mcollina 🙇

@lpinca
Copy link
Member

lpinca commented Mar 5, 2021

I'm closing this as it was addressed by #37060.

@lpinca lpinca closed this as completed Mar 5, 2021
@severn-everett
Copy link

@mcollina Why was this not reverted on master? I'm running into the same issue on 16.3.0.

@ronag
Copy link
Member

ronag commented Jun 3, 2021

@severn-everett Because the new behavior is considered correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stream Issues and PRs related to the stream subsystem. zlib Issues and PRs related to the zlib subsystem.
Projects
None yet
Development

No branches or pull requests

8 participants